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

[Ludwig Krispenz]

On 05/28/2015 05:03 PM, Martin Kosek wrote:
> On 05/28/2015 04:59 PM, Ludwig Krispenz wrote:
>> On 05/28/2015 04:46 PM, Simo Sorce wrote:
>>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz 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.
>>>>>
>>>>> 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.
>>>> Hi Simo,
>>>>
>>>> you say the topology plugin should only activate itself if the domain
>>>> level is >= 1, at the moment this is done
>>>> by checking if plugin_version (1.0) >= domain_level (1).
>>> I do not understand what this means
>>>
>>>> If you want a different method/fields for decision, how do you want it
>>>> handled ?
>>> I do not see why you need to check for the topology plugin version, what
>>> you need is a "min_domain_level" version for now and just check:
>>> if domain_level >= min_domain_level:
>>>      do stuff
>> but right now installation sets
>> ipaMinDomainLevel: 0
>> ipaMaxDomainLevel: 1
>>
>> in the master entry, so we would always do stuff.
> Topology should not care about these settings at all, this is only for
> domainlevel API to validate if the level can be raised or not. Topology plugin
> should be only checking the effective Domain Level in cn=ipa,cn=etc,SUFFIX.
and then ? it reads domain level to be say 1, what is the trigger.
now I am confused, Simo say it should not compare it to the plugin 
version, you say it should not compare to the server level,

so what ? hard code on domain level 1?
>
>>> In the future we may grow more complex requirements and activate 'parts'
>>> of the plugin based on the domain level, so you could have something
>>> like:
>>>
>>> if domain_level >= min_domain_level:
>>>      do basic stuff
>>>      if domain_level >= feature_X_min_domain_level:
>>>          enable feature X
>>>
>>>
>>> So a general topology plugin version is not really interesting, the code
>>> above may still be there in version 5.0 of the topology plugin.
>>> We need a general minimum domain level version and then in future
>>> per-feature minimum domain level checks.
>>>
>>> Simo.
>>>
>>>