On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote: > On 05/28/2015 05:03 PM, Martin Kosek wrote: > > On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: > >> On 05/28/2015 04:46 PM, Simo Sorce wrote: > >>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: > >>>> On 05/28/2015 03:26 PM, Simo Sorce wrote: > >>>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > >>>>>> On 28.5.2015 10:49, Martin Kosek wrote: > >>>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > >>>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: > >>>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>>>>>>>> Hello, > >>>>>>>>>>>>> > >>>>>>>>>>>>> it came to my mind that domain level for topology plugin should > >>>>>>>>>>>>> actually be > >>>>>>>>>>>>> number 2, not 1. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree > >>>>>>>>>>>>> and I > >>>>>>>>>>>>> believe > >>>>>>>>>>>>> that it is not a good idea to have two places which say > >>>>>>>>>>>>> 'version 1' > >>>>>>>>>>>>> but and > >>>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain > >>>>>>>>>>>>> level 1) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Patch is attached. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> Hello, > >>>>>>>>>>>> The fix looks good but that seems strange to have to set the > >>>>>>>>>>>> initial > >>>>>>>>>>>> version of > >>>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will > >>>>>>>>>>>> be > >>>>>>>>>>>> written in > >>>>>>>>>>>> dse.ldif) > >>>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate > >>>>>>>>>>>> itself if the > >>>>>>>>>>>> DomainLevel is 2.0 or more. > >>>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 > >>>>>>>>>>>> then > >>>>>>>>>>>> activate > >>>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>>>>>>>> > >>>>>>>>>>>> Let's wait for Ludwig feedback. > >>>>>>>>>>>> > >>>>>>>>>>>> thanks > >>>>>>>>>>>> thierry > >>>>>>>>>>> My personal opinion on this is to start with Domain Level 1 > >>>>>>>>>>> regardless. We > >>>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async > >>>>>>>>>>> updates etc. I > >>>>>>>>>>> do not think we will be returning to implementing proper Domain > >>>>>>>>>>> Level > >>>>>>>>>>> support > >>>>>>>>>>> for that anyway. > >>>>>>>>>>> > >>>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is > >>>>>>>>>>> unused, 2 is > >>>>>>>>>>> the top one" will cause unforeseen issues I would rather like to > >>>>>>>>>>> avoid. > >>>>>>>>>> I'm more worried about confusion in future. To to me it simply > >>>>>>>>>> seems > >>>>>>>>>> easier to > >>>>>>>>>> bump one integer now than to document and explain (to users & new > >>>>>>>>>> developers) > >>>>>>>>>> why we have two "ones" which mean something else. > >>>>>>>>>> > >>>>>>>>>> Code-wise it is just an integer. > >>>>>>>>>> > >>>>>>>>>> Also, it can simplify logic in future when we decide to do another > >>>>>>>>>> incompatible change in DNS tree because we will have only one > >>>>>>>>>> integer > >>>>>>>>>> to test > >>>>>>>>>> (instead of checking two separate version attribute in DNS tree & > >>>>>>>>>> domain > >>>>>>>>>> level). > >>>>>>>>> +1, but I think the minimum supported domain level should be 1, not > >>>>>>>>> 0, > >>>>>>>>> because > >>>>>>>>> 0 means the server uses the old DNS schema, which we do not support > >>>>>>>>> anymore, > >>>>>>>>> right? > >>>>>>>> Good point! > >>>>>>>> > >>>>>>> It may be a good point, but it does not make the situation easier. > >>>>>>> You still > >>>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support > >>>>>>> the new > >>>>>>> DNS forwarders and some don't - and neither of them support Domain > >>>>>>> Levels - > >>>>>>> i.e. have Domain Level 0. > >>>>>>> > >>>>>>> As I said, I still see more complications with this proposals than > >>>>>>> benefits... > >>>>>> I would argue that it actually helps. > >>>>>> > >>>>>> If domain level = 1 then we can be *sure* that all replicas support > >>>>>> the new > >>>>>> DNS semantics. > >>>>>> > >>>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) > >>>>>> and > >>>>>> it is > >>>>>> a warning sign for diagnostic tools and also us when it comes to > >>>>>> debugging. > >>>>> First of all a domain level is something we change *RARELY*, and it is > >>>>> a whole number and it is an all or nothing thing. > >>>>> > >>>>> I do not understand why plugin versions matter at all, plugin version > >>>>> have nothing to do with domain levels. Each plugin *whatever* the > >>>>> version MUST always support at least 2 levels, because every domain you > >>>>> have will have to go through a domain_level transition when a new domain > >>>>> level comes out. > >>>>> > >>>>> Finally no single developer should be allowed to decide on anew domain > >>>>> level, this must be a well ponder team decision as all plugins that need > >>>>> to change behavior based on domain level will be affected so a thorough > >>>>> review of what changes are needed across all plugins must be done every > >>>>> time someone propose a change that requires a domain level bump. > >>>>> > >>>>> Last but not least we should consider domain levels as something that > >>>>> changes *very* slowly, because otherwise you'll have to support many > >>>>> domain levels within any plugins that have to change behavior according > >>>>> to the domain level. > >>>>> I would say that the domain level should not change more frequently than > >>>>> once a year or so. It would be too much code churn to do otherwise. > >>>>> > >>>>> So for now domain_level should be set to 0. And the topology plugin will > >>>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 > >>>>> until we have the replica promotion code at least, because only then we > >>>>> can make full use of the topology plugins. > >>>>> > >>>>> The DNS mess is unfixable, unless Petr you volunteer to backport code to > >>>>> change the behavior of the DNS based on the domain level, if that's the > >>>>> case then you can tie old behavior to level 0 and new behavior to level > >>>>>> = 1, but I do not think you want to do that given we already have > >>>>> "level 0" servers that sport the new code and changed the data in the > >>>>> directory, so let's just ignore DNS for the purpose of this discussion, > >>>>> except for nothing that once we finally switch to level 1 then all > >>>>> servers must be running with the newer DNS schema and older is not > >>>>> supported. > >>>>> > >>>>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the > >>>>> domain level is one for the whole server, I want to make it very clear, > >>>>> because the title and part of the discussion seem to imply that you have > >>>>> per-plugin domain levels. If anything like that actually exist in the > >>>>> topology plugin code it must be ripped out now, plugin version and > >>>>> domain level are completely disjointed things and no correlation should > >>>>> or can exist, the only thing that can exist is whether the server, as a > >>>>> whole, supports a specific domain level or not. > >>>>> > >>>>> So once we decide domain level X comes to existence we basically freeze > >>>>> what it means and any new development that may require a domain level > >>>>> bump risk being delayed until we are ready for a new domain level bump, > >>>>> which should not happen very often. > >>>>> > >>>>> So let's make it very clear what level 1 means because the next release > >>>>> will then support only 0 and 1, and once a new version will come out > >>>>> with support for "level 2" we want be able to use any of the features > >>>>> tied to level 2 until all servers in the next release have been > >>>>> upgraded, and that may be a years long process, so we can't just churn > >>>>> domain level numbers as we need to support working on older levels for > >>>>> extended periods. > >>>> Hi Simo, > >>>> > >>>> you say the topology plugin should only activate itself if the domain > >>>> level is >= 1, at the moment this is done > >>>> by checking if plugin_version (1.0) >= domain_level (1). > >>> I do not understand what this means > >>> > >>>> If you want a different method/fields for decision, how do you want it > >>>> handled ? > >>> I do not see why you need to check for the topology plugin version, what > >>> you need is a "min_domain_level" version for now and just check: > >>> if domain_level >= min_domain_level: > >>> do stuff > >> but right now installation sets > >> ipaMinDomainLevel: 0 > >> ipaMaxDomainLevel: 1 > >> > >> in the master entry, so we would always do stuff. > > Topology should not care about these settings at all, this is only for > > domainlevel API to validate if the level can be raised or not. Topology > > plugin > > should be only checking the effective Domain Level in cn=ipa,cn=etc,SUFFIX. > and then ? it reads domain level to be say 1, what is the trigger. > now I am confused, Simo say it should not compare it to the plugin > version, you say it should not compare to the server level, > > so what ? hard code on domain level 1?
In the plugin you should have this variable as a global (for the plugin) int topology_min_domain_level = 1 You *know* the plugin can activate only if domain_level is 1, it is ok to hard code it, once we release the code we will never change this. The plugin will be forever and ever enabled only if the global domain level you read from cn=ipa,cn=etc,SUFFIX is >= 1 It doesn't matter if in 2025 we are at topology plugin version 7.0 and the domain level supported are now 0 through 42, you will still enable the basic behavior at domain level >= 1 Later on additional features may be conditional on other domain levels, and eventually we may even become incompatible with domain level 1 and require a higher level, but that will always be something you know statically in the code, you will never have a reason or a way to dynamically change domain level support within the plugin. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
