On Thu, 2015-05-28 at 16:40 +0200, Martin Basti wrote: > On 28/05/15 16:29, Simo Sorce wrote: > > On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote: > >> Hi Simo, > >> > >> On 05/28/2015 03:52 PM, Simo Sorce wrote: > >>> On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans 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. > >>>> Does that mean, that by default domain level must be set to 0 and only > >>>> raised manually by the identity admin? > >>> Yes, the domain level is established by the first server you install, > >>> and CANNOT be raise automatically by a replica, it must be always > >>> manually raised by the admin. Moreover the code that raises *MUST* check > >>> that all server are capable of handling the new domain level or refuse > >>> to raise the level. > >>> This means all servers must publish the range of domain levels they > >>> support, a missing range means only level 0 is supported. > >> Thank you, this at last clarifies most of the use-cases. > >> The only question that remains: what will happen if an admin (for > >> whatever dumb reason) decides to downgrade the FreeIPA version to 4.1 > >> (that does not support domain > >> levels) on the master of the domain that has domain level = 1? Do replicas > >> preserve the information > >> of the topology? Do they delete this info from DS together with the record > >> about the domain > >> level? Should we support such scenario at all? > > We do not support downgrades, probably everything will explode on the > > server if you even try :-) > > > > We just change so much not only in the directory but also in local > > configuration. I think in recent discussions we also said the updater > > will check what is the current version and just bail out on applying > > anything on "downgrades". So nothing would be changed in the directory > > and Freeipa should just fail to start (or worse). > > > > > Actually, IPA 4-1 has old upgrade script, so it will be possible to run > upgrade and break server.
Yep, the upgrade thing is for the future, older servers will just break all. Again downgrades are not supported. 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