On 28.5.2015 15:26, 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.

I do not see a problem with using level = 2 for topology plugin but whatever.
Be it as Simo designed.

-- 
Petr^2 Spacek

-- 
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

Reply via email to