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
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.
--
Simo Sorce * Red Hat, Inc * New York
--
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
