Re: [Freeipa-devel] Domain level for topology plugin = 2
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[Freeipa-devel] Domain level for topology plugin = 2
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. -- Petr^2 Spacek From 447ab9bac54e6857e8f2266a5b378ebfc1c7afe8 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Tue, 26 May 2015 14:09:34 +0200 Subject: [PATCH] Bump domain level for topology plugin to 2. Level 1 already used for incompatible changes in DNS schema. --- daemons/ipa-slapi-plugins/topology/topology.h | 2 +- ipalib/constants.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-slapi-plugins/topology/topology.h b/daemons/ipa-slapi-plugins/topology/topology.h index 38c2823f50153c6b02a234608869617c92d1bdf2..9a3c7e46eb8211c1f7a57a1f15346a0ca6e6a4ac 100644 --- a/daemons/ipa-slapi-plugins/topology/topology.h +++ b/daemons/ipa-slapi-plugins/topology/topology.h @@ -10,7 +10,7 @@ #define PLUGIN_NAMEipa-topology-plugin #define PLUGIN_VENDOR freeipa -#define PLUGIN_VERSION 1.0 +#define PLUGIN_VERSION 2.0 #define IPA_TOPO_PLUGIN_SUBSYSTEM ipa-topology-plugin #define IPA_TOPO_PREOP_DESC ipa-topology-preop-subplugin diff --git a/ipalib/constants.py b/ipalib/constants.py index b99306eaec1d7bcbec4612a8aa4a599d02ac73e5..bdea1e86c6b77fc3e0123d43c9ca5b0acd7bdb73 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -226,4 +226,4 @@ IPA_ANCHOR_PREFIX = ':IPA:' SID_ANCHOR_PREFIX = ':SID:' MIN_DOMAIN_LEVEL = 0 -MAX_DOMAIN_LEVEL = 1 +MAX_DOMAIN_LEVEL = 2 -- 2.1.0 -- 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
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
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
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
