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

2015-05-28 Thread Martin Kosek

On 05/28/2015 05:53 PM, Ludwig Krispenz wrote:


On 05/28/2015 05:35 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote:

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, 

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

2015-05-28 Thread Ludwig Krispenz


On 05/27/2015 01:04 PM, Martin Kosek wrote:

On 05/26/2015 04:32 PM, Petr Spacek wrote:

On 26.5.2015 16:16, Martin Kosek wrote:

...

If you really want to avoid unforeseen issues rather go and get rid of
major.minor logic we have in the topology plugin right now :-)

Ludwig, I thought we agreed to avoid using major.minor format in the topology
plugin Domain Level implementation, to both avoid confusion of users and to not
ship unused code - right?
The user does not see major/minor, so no confusion. All the plugin 
versions have the format 1.0 or alike and I converted the single integer 
domain level internally to compare to the plugin version

Thanks,
Martin


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


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

2015-05-28 Thread Jan Cholasta

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?




If you really want to avoid unforeseen issues rather go and get rid of
major.minor logic we have in the topology plugin right now :-)




--
Jan Cholasta

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


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

2015-05-28 Thread Petr Spacek
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!

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


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

2015-05-28 Thread Simo Sorce
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 

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

2015-05-28 Thread 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 

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

2015-05-28 Thread Oleg Fayans
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 

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

2015-05-28 Thread Simo Sorce
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 

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

2015-05-28 Thread Martin Basti

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 

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

2015-05-28 Thread Simo Sorce
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 

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

2015-05-28 Thread Simo Sorce
On Thu, 2015-05-28 at 10:46 -0400, 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 

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

2015-05-28 Thread Ludwig Krispenz


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 

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

2015-05-28 Thread Simo Sorce
On Thu, 2015-05-28 at 16:59 +0200, 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 

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

2015-05-28 Thread 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 

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

2015-05-28 Thread Simo Sorce
On Thu, 2015-05-28 at 16:40 +0200, Martin Basti wrote:
 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 

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

2015-05-28 Thread Martin Kosek
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 

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

2015-05-28 Thread Ludwig Krispenz


On 05/28/2015 05:35 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote:

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 

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

2015-05-28 Thread Simo Sorce
On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote:
 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 

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

2015-05-27 Thread Martin Kosek
On 05/26/2015 04:32 PM, Petr Spacek wrote:
 On 26.5.2015 16:16, Martin Kosek wrote:
...
 If you really want to avoid unforeseen issues rather go and get rid of
 major.minor logic we have in the topology plugin right now :-)

Ludwig, I thought we agreed to avoid using major.minor format in the topology
plugin Domain Level implementation, to both avoid confusion of users and to not
ship unused code - right?

Thanks,
Martin

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


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

2015-05-26 Thread Martin Kosek

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.


My 2 cents.

Martin

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


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

2015-05-26 Thread thierry bordaz

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

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

2015-05-26 Thread Petr Spacek
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).

If you really want to avoid unforeseen issues rather go and get rid of
major.minor logic we have in the topology plugin right now :-)

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