<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Simo, <div class="moz-cite-prefix">On 05/28/2015 03:52 PM, Simo Sorce wrote: </div> <blockquote cite="mid:1432821163.19096.146.camel@willson.usersys.redhat.com" type="cite"> <pre wrap="">On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: </pre> <blockquote type="cite"> <pre wrap=""> On 05/28/2015 03:26 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 28.5.2015 10:49, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/28/2015 09:05 AM, Petr Spacek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 28.5.2015 08:55, Jan Cholasta wrote: </pre> <blockquote type="cite"> <pre wrap="">Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): </pre> <blockquote type="cite"> <pre wrap="">On 26.5.2015 16:16, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/26/2015 04:13 PM, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/26/2015 02:12 PM, Petr Spacek wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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 </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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). </pre> </blockquote> <pre wrap="">+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? </pre> </blockquote> <pre wrap="">Good point! </pre> </blockquote> <pre wrap="">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... </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Does that mean, that by default domain level must be set to 0 and only raised manually by the identity admin? </pre> </blockquote> <pre wrap=""> Yes, the domain level is established by the first server you install, and CANNOT be raise automatically by a replica, it must be always manually raised by the admin. Moreover the code that raises *MUST* check that all server are capable of handling the new domain level or refuse to raise the level. This means all servers must publish the range of domain levels they support, a missing range means only level 0 is supported.</pre> </blockquote> Thank you, this at last clarifies most of the use-cases. The only question that remains: what will happen if an admin (for whatever dumb reason) decides to downgrade the FreeIPA version to 4.1 (that does not support domain levels) on the master of the domain that has domain level = 1? Do replicas preserve the information of the topology? Do they delete this info from DS together with the record about the domain level? Should we support such scenario at all? <blockquote cite="mid:1432821163.19096.146.camel@willson.usersys.redhat.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">In the official FreeIPA documentation we explicitly require software version of replicas to be not below the corresponding version of master. That means that replicas will in all cases support this feature. Or did I get it all wrong? </pre> </blockquote> <pre wrap=""> What it means is that replicas must support the domain level version of the domain in order to join. It is another reason we want the replica promotion code as this code will also check the domain level is suitable and refuse to continue if the domain level is not supported. It will have to spit an error like: "Domain Level too old, please upgrade your domain to at least level 'X' before trying to join this server" Note: I've put freeipa-devel back in CC as this is useful information for all developers. Simo. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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 </pre> <blockquote type="cite"> <pre wrap="">= 1, but I do not think you want to do that given we already have </pre> </blockquote> <pre wrap="">"level 0" servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this discussion, except for nothing that once we finally switch to level 1 then all servers must be running with the newer DNS schema and older is not supported. Ah, I almost forgot, there is no "domain level for XYZ plugin", the domain level is one for the whole server, I want to make it very clear, because the title and part of the discussion seem to imply that you have per-plugin domain levels. If anything like that actually exist in the topology plugin code it must be ripped out now, plugin version and domain level are completely disjointed things and no correlation should or can exist, the only thing that can exist is whether the server, as a whole, supports a specific domain level or not. So once we decide domain level X comes to existence we basically freeze what it means and any new development that may require a domain level bump risk being delayed until we are ready for a new domain level bump, which should not happen very often. So let's make it very clear what level 1 means because the next release will then support only 0 and 1, and once a new version will come out with support for "level 2" we want be able to use any of the features tied to level 2 until all servers in the next release have been upgraded, and that may be a years long process, so we can't just churn domain level numbers as we need to support working on older levels for extended periods. Simo. </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Oleg Fayans Quality Engineer FreeIPA team RedHat.</pre> </body> </html>