[Freeipa-devel] Domain level for topology plugin = 2

[Simo Sorce]

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