On 28.5.2015 15:26, 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.
I do not see a problem with using level = 2 for topology plugin but whatever. Be it as Simo designed. -- Petr^2 Spacek -- 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