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

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