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

[Ludwig Krispenz]

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.
yes, for the first time it is raised, but if you install a new replica 
it will be initialized from an existing replica in the domain
and teh domain level is in the shared tree, so the new replica will have 
it automatically
>   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.
>
>> In the official FreeIPA documentation we explicitly require software
>> version of replicas to be not below the
>> corresponding version of master. That means that replicas will in all
>> cases support this feature. Or did I get it all wrong?
> What it means is that replicas must support the domain level version of
> the domain in order to join. It is another reason we want the replica
> promotion code as this code will also check the domain level is suitable
> and refuse to continue if the domain level is not supported.
>
> It will have to spit an error like: "Domain Level too old, please
> upgrade your domain to at least level 'X' before trying to join this
> server"
>
> Note: I've put freeipa-devel back in CC as this is useful information
> for all developers.
>
> Simo.
>
>>> 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.
>>>
>>> Simo.
>>>
>