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

Martin Basti mbasti at redhat.com
Thu May 28 14:40:06 UTC 2015


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.

-- 
Martin Basti




More information about the Freeipa-devel mailing list