Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/15/2014 11:01 PM, Simo Sorce wrote: Hello fellow developers, I added this new design: http://www.freeipa.org/page/V4/Domain_Levels It is a prerequisite for both the Replica Promotion design: http://www.freeipa.org/page/V4/Replica_Promotion and the Topology plugins design: http://www.freeipa.org/page/V4/Manage_replication_topology (Ludwig will change this to include the changes we have discussed in a previous phone call, and which involve mostly Domain Level/Domain Upgrades/migrations issues) I've updated this now, it just needs a reviewer There is also a working implementation for this state, just some cleanup before review (or feedback from design review) As usual feel free to add as needed or comments and ask questions. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Mon, 05 Jan 2015 14:15:17 +0100 Martin Basti wrote: > On 15/12/14 23:01, Simo Sorce wrote: > > Hello fellow developers, I added this new design: > > http://www.freeipa.org/page/V4/Domain_Levels > > > > It is a prerequisite for both the Replica Promotion design: > > http://www.freeipa.org/page/V4/Replica_Promotion > > and the Topology plugins design: > > http://www.freeipa.org/page/V4/Manage_replication_topology > > (Ludwig will change this to include the changes we have discussed > > in a previous phone call, and which involve mostly Domain > > Level/Domain Upgrades/migrations issues) > > > > As usual feel free to add as needed or comments and ask questions. > > > > Simo. > > > I have a question, how domain levels are related to IPA Upgrade? > > Will we able to run LDAP update after increasing domain level, if new > feature requires some LDAP data modification? > > Or we just do upgrade as we do now, and new code has to be able to > handle data in both new and old way. We'll have to be able to work on a range of levels. This means some updates may need to be conditional to the domain level. This also means the tool to raise the level may need to run some updates. I think we may want to start adding a level option at some point in updates, but we'll work it out when we get there I guess. > For example: > Forwardzone feature, old "forwardzones" and new forwardzones are not > compatible. It requires to change LDAP data, move fake "forwardzones" > to new objectclass. We will simply not accept incompatible changes, at least not on mere upgrades, we simply can't. The fact we have in the past has been a team communication failure in my view. > This should happen after increasing domain > level. Are we able to do that? (In current upgrade, forwardzones are > hidden in old replicas, user should use only new replica to > add/del/mod forwardzones) The challenge is in planning changes so that upgrades are not difficult to implement. Every developer MUST (int the RFC sense :-) think what are the consequences of the changes they are proposing/implementing on upgrades. FreeIPA is a distributed system, and people must think in that sense in general. If we corner ourselves in a situation where it is very hard to perform an upgrade that is our own failure. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 15/12/14 23:01, Simo Sorce wrote: Hello fellow developers, I added this new design: http://www.freeipa.org/page/V4/Domain_Levels It is a prerequisite for both the Replica Promotion design: http://www.freeipa.org/page/V4/Replica_Promotion and the Topology plugins design: http://www.freeipa.org/page/V4/Manage_replication_topology (Ludwig will change this to include the changes we have discussed in a previous phone call, and which involve mostly Domain Level/Domain Upgrades/migrations issues) As usual feel free to add as needed or comments and ask questions. Simo. I have a question, how domain levels are related to IPA Upgrade? Will we able to run LDAP update after increasing domain level, if new feature requires some LDAP data modification? Or we just do upgrade as we do now, and new code has to be able to handle data in both new and old way. For example: Forwardzone feature, old "forwardzones" and new forwardzones are not compatible. It requires to change LDAP data, move fake "forwardzones" to new objectclass. This should happen after increasing domain level. Are we able to do that? (In current upgrade, forwardzones are hidden in old replicas, user should use only new replica to add/del/mod forwardzones) Martin^2 -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Fri, 19 Dec 2014 17:01:56 +0100 Ludwig Krispenz wrote: > > On 12/18/2014 02:52 PM, Simo Sorce wrote: > > On Thu, 18 Dec 2014 10:56:47 +0100 > > thierry bordaz wrote: > > > >> On 12/16/2014 05:44 PM, Simo Sorce wrote: > >>> On Tue, 16 Dec 2014 10:40:20 -0500 > >>> Simo Sorce wrote: > >>> > On Tue, 16 Dec 2014 15:57:34 +0100 > Ludwig Krispenz wrote: > > > On 12/16/2014 03:22 PM, Simo Sorce wrote: > >> On Tue, 16 Dec 2014 11:33:41 +0100 > >> Ludwig Krispenz wrote: > >> > >>> Hi Simo, > >>> > >>> one thing is not quite clear to me: do you want a domain level > >>> per feature or a global domain level or both ? > >> The Domain Level is global. > >> I described a "Feature Version" that is published by feature. > >> The Feature Versions just state what is available they do not > >> determine what is the current overall Domain Level. > > Ok, just to confirm my understanding. > > > > - we have one domain level. > Yes. > >> Hello, > >> > >> Domain level can only be increased. Can it interfere with the > >> ability of the admin to downgrade a software version ? > > Yes it will interfere, but the domain level will never be > > automatically raised, so the admin has time to do tests for normal > > functionality, and can wait to raise the domain level if there are > > reports of issues with newer functionality. > there is one more scenario I would like to clarify. If a new replica > is installed or a client promoted to a replica, this means th enew > installation of a DS instance, which for some time is not connected > to the rest of the topology until its shared date are initialized > from an existing server in the topology. After the total init is > complete, it can check the set domain level and act accordingly. > But how should it act before, assuming domain level 0, or should > admin/scripts set a temporary domain level in the neew server, even > if it will be overwritten later by replica initialization ? I would assume 0 until told otherwise for now. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/18/2014 02:52 PM, Simo Sorce wrote: On Thu, 18 Dec 2014 10:56:47 +0100 thierry bordaz wrote: On 12/16/2014 05:44 PM, Simo Sorce wrote: On Tue, 16 Dec 2014 10:40:20 -0500 Simo Sorce wrote: On Tue, 16 Dec 2014 15:57:34 +0100 Ludwig Krispenz wrote: On 12/16/2014 03:22 PM, Simo Sorce wrote: On Tue, 16 Dec 2014 11:33:41 +0100 Ludwig Krispenz wrote: Hi Simo, one thing is not quite clear to me: do you want a domain level per feature or a global domain level or both ? The Domain Level is global. I described a "Feature Version" that is published by feature. The Feature Versions just state what is available they do not determine what is the current overall Domain Level. Ok, just to confirm my understanding. - we have one domain level. Yes. Hello, Domain level can only be increased. Can it interfere with the ability of the admin to downgrade a software version ? Yes it will interfere, but the domain level will never be automatically raised, so the admin has time to do tests for normal functionality, and can wait to raise the domain level if there are reports of issues with newer functionality. there is one more scenario I would like to clarify. If a new replica is installed or a client promoted to a replica, this means th enew installation of a DS instance, which for some time is not connected to the rest of the topology until its shared date are initialized from an existing server in the topology. After the total init is complete, it can check the set domain level and act accordingly. But how should it act before, assuming domain level 0, or should admin/scripts set a temporary domain level in the neew server, even if it will be overwritten later by replica initialization ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Thu, 18 Dec 2014 15:26:51 +0100 Ludwig Krispenz wrote: > > >> Hello, > >> > >> Domain level can only be increased. Can it interfere with the > >> ability of the admin to downgrade a software version ? > > Yes it will interfere, but the domain level will never be > > automatically raised, so the admin has time to do tests for normal > > functionality, and can wait to raise the domain level if there are > > reports of issues with newer functionality. > I think Thierry had the opposite direrction im mind. Everything is > fine, the domain level is raised and then on one server the admin > does a downgrade of ipa. Is this possible, what would happen ? Things will probably start breaking, don't do that. We do not support downgrades even now, so nothing new. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/18/2014 03:26 PM, Ludwig Krispenz wrote: > >>> Hello, >>> >>> Domain level can only be increased. Can it interfere with the ability >>> of the admin to downgrade a software version ? >> Yes it will interfere, but the domain level will never be automatically >> raised, so the admin has time to do tests for normal functionality, and >> can wait to raise the domain level if there are reports of issues with >> newer functionality. > I think Thierry had the opposite direrction im mind. Everything is fine, the > domain level is raised and then on one server the admin does a downgrade of > ipa. Is this possible, what would happen ? IPA does not support downgrades (AFAIK) - there is no ipa-ldap-downgrade command. It may work, it may not work - you are on your own here. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
Hello, Domain level can only be increased. Can it interfere with the ability of the admin to downgrade a software version ? Yes it will interfere, but the domain level will never be automatically raised, so the admin has time to do tests for normal functionality, and can wait to raise the domain level if there are reports of issues with newer functionality. I think Thierry had the opposite direrction im mind. Everything is fine, the domain level is raised and then on one server the admin does a downgrade of ipa. Is this possible, what would happen ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Thu, 18 Dec 2014 10:56:47 +0100 thierry bordaz wrote: > On 12/16/2014 05:44 PM, Simo Sorce wrote: > > On Tue, 16 Dec 2014 10:40:20 -0500 > > Simo Sorce wrote: > > > >> On Tue, 16 Dec 2014 15:57:34 +0100 > >> Ludwig Krispenz wrote: > >> > >>> On 12/16/2014 03:22 PM, Simo Sorce wrote: > On Tue, 16 Dec 2014 11:33:41 +0100 > Ludwig Krispenz wrote: > > > Hi Simo, > > > > one thing is not quite clear to me: do you want a domain level > > per feature or a global domain level or both ? > The Domain Level is global. > I described a "Feature Version" that is published by feature. > The Feature Versions just state what is available they do not > determine what is the current overall Domain Level. > >>> Ok, just to confirm my understanding. > >>> > >>> - we have one domain level. > >> Yes. > Hello, > > Domain level can only be increased. Can it interfere with the ability > of the admin to downgrade a software version ? Yes it will interfere, but the domain level will never be automatically raised, so the admin has time to do tests for normal functionality, and can wait to raise the domain level if there are reports of issues with newer functionality. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/16/2014 05:44 PM, Simo Sorce wrote:
On Tue, 16 Dec 2014 10:40:20 -0500
Simo Sorce wrote:
On Tue, 16 Dec 2014 15:57:34 +0100
Ludwig Krispenz wrote:
On 12/16/2014 03:22 PM, Simo Sorce wrote:
On Tue, 16 Dec 2014 11:33:41 +0100
Ludwig Krispenz wrote:
Hi Simo,
one thing is not quite clear to me: do you want a domain level
per feature or a global domain level or both ?
The Domain Level is global.
I described a "Feature Version" that is published by feature.
The Feature Versions just state what is available they do not
determine what is the current overall Domain Level.
Ok, just to confirm my understanding.
- we have one domain level.
Yes.
Hello,
Domain level can only be increased. Can it interfere with the ability of
the admin to downgrade a software version ?
thanks
thierry
- each (new) plugin or compoment has to define its minimal domain
level and execute only features covered by this level
Each plugin may have different behavior based on the domain level it
is enabled, however the highest level is open-ended. IE a plugin must
not stop working if it see a higher level than was known when it was
built.
SO a plugin may have an if/else like this:
if (level < MIN_DOM_LEVEL) {
return;
} else if (level < XYZ_DOM_LEVEL) {
/* do something */
} else {
/* do something else */
}
The last branch is always there unless we are going to stop using a
plugin and intentionally want it to stop working once the domain level
is raised past the XYZ_DOM_LEVEL (whatever that will be).
- in addition, these plugins have to expose their (plugin) version
on each server, allowing checks for setting the domain level
Yes,
we can refine this part though, for example each plugin could publish
the minimum domain level is supports instead of a version number if
that is useful or easier to manage. But this is not sufficient to do
checks, we still need to know, in some cases, also what is the
maximum level known for some plugins (but not for others), so we'll
still need a detailed list of things to check.
If this is too complex however, maybe we can simply publish a
"supported domain level" number per server, and deal internally within
a server on how to publish it.
A "supported domain levels" range really, so we can say IPA v8.0 support
level 2-3-4 but not 0 or 1 or 5 (which is supported only by v9.0
Actually, I think I will go and change the proposal this way, it will
make it much easier to deal with for checks.
Simo.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Wed, 17 Dec 2014 13:56:24 +0100 Ludwig Krispenz wrote: > > On 12/17/2014 12:59 PM, Martin Kosek wrote: > > On 12/15/2014 11:01 PM, Simo Sorce wrote: > >> Hello fellow developers, I added this new design: > >> http://www.freeipa.org/page/V4/Domain_Levels > >> > >> It is a prerequisite for both the Replica Promotion design: > >> http://www.freeipa.org/page/V4/Replica_Promotion > >> and the Topology plugins design: > >> http://www.freeipa.org/page/V4/Manage_replication_topology > >> (Ludwig will change this to include the changes we have discussed > >> in a previous phone call, and which involve mostly Domain > >> Level/Domain Upgrades/migrations issues) > >> > >> As usual feel free to add as needed or comments and ask questions. > >> > >> Simo. > >> > > Thanks! For starters, please follow > > > > http://www.freeipa.org/page/Feature_template > > > > next time :-) Don't worry, I updated current proposal to follow it. > > > > On top of what was already said, I have couple comments: > > > > > > 1) Relation between domain levels and FreeIPA versions > > > > It is now proposed as "numbers", how do we define the relation? Did > > you want to create new domain level on needed basis? So we would > > have mapping like > > > > Domain level 0 --> FreeIPA 4.1 or older > > Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology > > plugin user life cycle > > Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client > > Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts > > > > ? Would it be more transparent to simply use versions as AD does > > [1] and always define which features require it? I.e.: > > > > Domain level "4.2" > > Domain level "4.3" --> thin API client > > Domain level "4.4" --> no changes > > Domain level "5.0" --> IPA-IPA trusts > > > > > > 2) Backporting features > > Long standing problem with API version was if for example > > RHEL/CentOS 6.6 does not rebase, but only backports selected > > patches/features from higher versions. Should it bump the > > API/supported Domain Level? > > > > Or should it only bump Domain Level if and only if it backports > > *all* features for the respective domain level? > which function would detect if "all" features are backported, and > which function would bump the server level ? A function implemented by the framework. > maybe Simo's original proposal could be useful: each feature > registers its feature level in the server entry, eg "topology/1.0", > so all baclported features would be visible we can retain the publishing of the individual features, but we probably want to use only the coarse grained domain level range indicator to make a decision. Which means that if you lie because you backport some features and raise the level, but you do not backport them all, then the admin would be able to flip the switch to raise the level and then he may experience issues as the domain is not fully functional ... Simo. > > > > 3) Storing server and global domain level in LDAP > > I added [2]. > > > > > > [1] > > http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx > > [2] > > http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels > > > > ___ > > Freeipa-devel mailing list > > Freeipa-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/17/2014 03:52 PM, Simo Sorce wrote: > On Wed, 17 Dec 2014 12:59:56 +0100 > Martin Kosek wrote: > >> On 12/15/2014 11:01 PM, Simo Sorce wrote: >>> >>> Hello fellow developers, I added this new design: >>> http://www.freeipa.org/page/V4/Domain_Levels >>> >>> It is a prerequisite for both the Replica Promotion design: >>> http://www.freeipa.org/page/V4/Replica_Promotion >>> and the Topology plugins design: >>> http://www.freeipa.org/page/V4/Manage_replication_topology >>> (Ludwig will change this to include the changes we have discussed >>> in a previous phone call, and which involve mostly Domain >>> Level/Domain Upgrades/migrations issues) >>> >>> As usual feel free to add as needed or comments and ask questions. >>> >>> Simo. >>> >> >> Thanks! For starters, please follow >> >> http://www.freeipa.org/page/Feature_template >> >> next time :-) Don't worry, I updated current proposal to follow it. > > Ah you mean you broke and moved down one notch all the headings that I > changed one level up because the default ones are ugly ? :-) No? :-) In meadiawiki, the highest headings you are supposed to use is "==" as "=" generates header and there should be just one on the page - and that is the page name. > Why do you start at == level instead of = ? See the note in http://www.mediawiki.org/wiki/Help:Formatting#Level_2 This is the reason why I changed levels in the Feature template - to drive the good mediawiki practices. > Starting at == makes === almost disappear within the text and sections > do not stand up anymore ... Then the problem is not in levels, but in the CSS we use - this is something we can fix. >> On top of what was already said, I have couple comments: >> >> >> 1) Relation between domain levels and FreeIPA versions >> >> It is now proposed as "numbers", how do we define the relation? Did >> you want to create new domain level on needed basis? > > It is totally on a need to change basis. > >> So we would have mapping like >> >> Domain level 0 --> FreeIPA 4.1 or older >> Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin >> user life cycle >> Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client >> Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts > > NO. > We change Domain Level only when there is a well defined *need*. > > If we change something that absolutely requires all of the servers to > have it/update it then we have a candidate reason for a level change. > Otherwise not. > >> ? Would it be more transparent to simply use versions as AD does [1] >> and always define which features require it? I.e.: >> >> Domain level "4.2" >> Domain level "4.3" --> thin API client >> Domain level "4.4" --> no changes >> Domain level "5.0" --> IPA-IPA trusts > > Certainly we'll need to document what Domain level a feature needs to > be activated, it will be necessary because said feature will have to > deactivate itself both in the CLI and UI if the domain level is not > high enough, and appropriate error messages need to be returned. I agree both on this comment and comment above. So you would like to push for numeric levels which we would then map in documentation with FreeIPA versions, right? > >> 2) Backporting features >> Long standing problem with API version was if for example RHEL/CentOS >> 6.6 does not rebase, but only backports selected patches/features >> from higher versions. Should it bump the API/supported Domain Level? > > If you create a frankenstein you need to make sure you backport all the > features necessary to interoperate at a specific domain level, or you > do not get to claim support for that level. > >> Or should it only bump Domain Level if and only if it backports *all* >> features for the respective domain level? > > Exactly, you have to be consistent. > >> 3) Storing server and global domain level in LDAP >> I added [2]. > > Thanks, although I think we'll need to store the domain level in it's > own object. The reason is that plugins may end up listening in to see > if it change and we do not want to have all of them parse every change > that goes into cn=ipaConfig all the time. > > So I will change the container name. Ok, makes sense. > > Simo. > >> >> [1] >> http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx >> [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels > > > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Wed, 17 Dec 2014 12:59:56 +0100 Martin Kosek wrote: > On 12/15/2014 11:01 PM, Simo Sorce wrote: > > > > Hello fellow developers, I added this new design: > > http://www.freeipa.org/page/V4/Domain_Levels > > > > It is a prerequisite for both the Replica Promotion design: > > http://www.freeipa.org/page/V4/Replica_Promotion > > and the Topology plugins design: > > http://www.freeipa.org/page/V4/Manage_replication_topology > > (Ludwig will change this to include the changes we have discussed > > in a previous phone call, and which involve mostly Domain > > Level/Domain Upgrades/migrations issues) > > > > As usual feel free to add as needed or comments and ask questions. > > > > Simo. > > > > Thanks! For starters, please follow > > http://www.freeipa.org/page/Feature_template > > next time :-) Don't worry, I updated current proposal to follow it. Ah you mean you broke and moved down one notch all the headings that I changed one level up because the default ones are ugly ? :-) Why do you start at == level instead of = ? Starting at == makes === almost disappear within the text and sections do not stand up anymore ... > On top of what was already said, I have couple comments: > > > 1) Relation between domain levels and FreeIPA versions > > It is now proposed as "numbers", how do we define the relation? Did > you want to create new domain level on needed basis? It is totally on a need to change basis. > So we would have mapping like > > Domain level 0 --> FreeIPA 4.1 or older > Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin > user life cycle > Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client > Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts NO. We change Domain Level only when there is a well defined *need*. If we change something that absolutely requires all of the servers to have it/update it then we have a candidate reason for a level change. Otherwise not. > ? Would it be more transparent to simply use versions as AD does [1] > and always define which features require it? I.e.: > > Domain level "4.2" > Domain level "4.3" --> thin API client > Domain level "4.4" --> no changes > Domain level "5.0" --> IPA-IPA trusts Certainly we'll need to document what Domain level a feature needs to be activated, it will be necessary because said feature will have to deactivate itself both in the CLI and UI if the domain level is not high enough, and appropriate error messages need to be returned. > 2) Backporting features > Long standing problem with API version was if for example RHEL/CentOS > 6.6 does not rebase, but only backports selected patches/features > from higher versions. Should it bump the API/supported Domain Level? If you create a frankenstein you need to make sure you backport all the features necessary to interoperate at a specific domain level, or you do not get to claim support for that level. > Or should it only bump Domain Level if and only if it backports *all* > features for the respective domain level? Exactly, you have to be consistent. > 3) Storing server and global domain level in LDAP > I added [2]. Thanks, although I think we'll need to store the domain level in it's own object. The reason is that plugins may end up listening in to see if it change and we do not want to have all of them parse every change that goes into cn=ipaConfig all the time. So I will change the container name. Simo. > > [1] > http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx > [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/17/2014 12:59 PM, Martin Kosek wrote: On 12/15/2014 11:01 PM, Simo Sorce wrote: Hello fellow developers, I added this new design: http://www.freeipa.org/page/V4/Domain_Levels It is a prerequisite for both the Replica Promotion design: http://www.freeipa.org/page/V4/Replica_Promotion and the Topology plugins design: http://www.freeipa.org/page/V4/Manage_replication_topology (Ludwig will change this to include the changes we have discussed in a previous phone call, and which involve mostly Domain Level/Domain Upgrades/migrations issues) As usual feel free to add as needed or comments and ask questions. Simo. Thanks! For starters, please follow http://www.freeipa.org/page/Feature_template next time :-) Don't worry, I updated current proposal to follow it. On top of what was already said, I have couple comments: 1) Relation between domain levels and FreeIPA versions It is now proposed as "numbers", how do we define the relation? Did you want to create new domain level on needed basis? So we would have mapping like Domain level 0 --> FreeIPA 4.1 or older Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin user life cycle Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts ? Would it be more transparent to simply use versions as AD does [1] and always define which features require it? I.e.: Domain level "4.2" Domain level "4.3" --> thin API client Domain level "4.4" --> no changes Domain level "5.0" --> IPA-IPA trusts 2) Backporting features Long standing problem with API version was if for example RHEL/CentOS 6.6 does not rebase, but only backports selected patches/features from higher versions. Should it bump the API/supported Domain Level? Or should it only bump Domain Level if and only if it backports *all* features for the respective domain level? which function would detect if "all" features are backported, and which function would bump the server level ? maybe Simo's original proposal could be useful: each feature registers its feature level in the server entry, eg "topology/1.0", so all baclported features would be visible 3) Storing server and global domain level in LDAP I added [2]. [1] http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/15/2014 11:01 PM, Simo Sorce wrote: > > Hello fellow developers, I added this new design: > http://www.freeipa.org/page/V4/Domain_Levels > > It is a prerequisite for both the Replica Promotion design: > http://www.freeipa.org/page/V4/Replica_Promotion > and the Topology plugins design: > http://www.freeipa.org/page/V4/Manage_replication_topology > (Ludwig will change this to include the changes we have discussed in a > previous phone call, and which involve mostly Domain Level/Domain > Upgrades/migrations issues) > > As usual feel free to add as needed or comments and ask questions. > > Simo. > Thanks! For starters, please follow http://www.freeipa.org/page/Feature_template next time :-) Don't worry, I updated current proposal to follow it. On top of what was already said, I have couple comments: 1) Relation between domain levels and FreeIPA versions It is now proposed as "numbers", how do we define the relation? Did you want to create new domain level on needed basis? So we would have mapping like Domain level 0 --> FreeIPA 4.1 or older Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin user life cycle Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts ? Would it be more transparent to simply use versions as AD does [1] and always define which features require it? I.e.: Domain level "4.2" Domain level "4.3" --> thin API client Domain level "4.4" --> no changes Domain level "5.0" --> IPA-IPA trusts 2) Backporting features Long standing problem with API version was if for example RHEL/CentOS 6.6 does not rebase, but only backports selected patches/features from higher versions. Should it bump the API/supported Domain Level? Or should it only bump Domain Level if and only if it backports *all* features for the respective domain level? 3) Storing server and global domain level in LDAP I added [2]. [1] http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Tue, 16 Dec 2014 10:40:20 -0500
Simo Sorce wrote:
> On Tue, 16 Dec 2014 15:57:34 +0100
> Ludwig Krispenz wrote:
>
> >
> > On 12/16/2014 03:22 PM, Simo Sorce wrote:
> > > On Tue, 16 Dec 2014 11:33:41 +0100
> > > Ludwig Krispenz wrote:
> > >
> > >> Hi Simo,
> > >>
> > >> one thing is not quite clear to me: do you want a domain level
> > >> per feature or a global domain level or both ?
> > > The Domain Level is global.
> > > I described a "Feature Version" that is published by feature.
> > > The Feature Versions just state what is available they do not
> > > determine what is the current overall Domain Level.
> > Ok, just to confirm my understanding.
> >
> > - we have one domain level.
>
> Yes.
>
> > - each (new) plugin or compoment has to define its minimal domain
> > level and execute only features covered by this level
>
> Each plugin may have different behavior based on the domain level it
> is enabled, however the highest level is open-ended. IE a plugin must
> not stop working if it see a higher level than was known when it was
> built.
>
> SO a plugin may have an if/else like this:
>
> if (level < MIN_DOM_LEVEL) {
>return;
> } else if (level < XYZ_DOM_LEVEL) {
>/* do something */
> } else {
>/* do something else */
> }
>
> The last branch is always there unless we are going to stop using a
> plugin and intentionally want it to stop working once the domain level
> is raised past the XYZ_DOM_LEVEL (whatever that will be).
>
> > - in addition, these plugins have to expose their (plugin) version
> > on each server, allowing checks for setting the domain level
>
> Yes,
> we can refine this part though, for example each plugin could publish
> the minimum domain level is supports instead of a version number if
> that is useful or easier to manage. But this is not sufficient to do
> checks, we still need to know, in some cases, also what is the
> maximum level known for some plugins (but not for others), so we'll
> still need a detailed list of things to check.
>
> If this is too complex however, maybe we can simply publish a
> "supported domain level" number per server, and deal internally within
> a server on how to publish it.
A "supported domain levels" range really, so we can say IPA v8.0 support
level 2-3-4 but not 0 or 1 or 5 (which is supported only by v9.0
Actually, I think I will go and change the proposal this way, it will
make it much easier to deal with for checks.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Tue, 16 Dec 2014 15:57:34 +0100
Ludwig Krispenz wrote:
>
> On 12/16/2014 03:22 PM, Simo Sorce wrote:
> > On Tue, 16 Dec 2014 11:33:41 +0100
> > Ludwig Krispenz wrote:
> >
> >> Hi Simo,
> >>
> >> one thing is not quite clear to me: do you want a domain level per
> >> feature or a global domain level or both ?
> > The Domain Level is global.
> > I described a "Feature Version" that is published by feature.
> > The Feature Versions just state what is available they do not
> > determine what is the current overall Domain Level.
> Ok, just to confirm my understanding.
>
> - we have one domain level.
Yes.
> - each (new) plugin or compoment has to define its minimal domain
> level and execute only features covered by this level
Each plugin may have different behavior based on the domain level it
is enabled, however the highest level is open-ended. IE a plugin must
not stop working if it see a higher level than was known when it was
built.
SO a plugin may have an if/else like this:
if (level < MIN_DOM_LEVEL) {
return;
} else if (level < XYZ_DOM_LEVEL) {
/* do something */
} else {
/* do something else */
}
The last branch is always there unless we are going to stop using a
plugin and intentionally want it to stop working once the domain level
is raised past the XYZ_DOM_LEVEL (whatever that will be).
> - in addition, these plugins have to expose their (plugin) version
> on each server, allowing checks for setting the domain level
Yes,
we can refine this part though, for example each plugin could publish
the minimum domain level is supports instead of a version number if that
is useful or easier to manage. But this is not sufficient to do checks,
we still need to know, in some cases, also what is the maximum level
known for some plugins (but not for others), so we'll still need a
detailed list of things to check.
If this is too complex however, maybe we can simply publish a
"supported domain level" number per server, and deal internally within
a server on how to publish it.
Simo.
> >
> >> For a single feature (eg topology management) it could be required
> >> that it is available on all servers, so it will be active only if
> >> it's domain level is set. But there could be another feature,
> >> independent of this one, it also could require to be installed on
> >> all servers, and wait until it's domain level is set.
> >> If we would only one domainlevel this would mean that all features
> >> need to be at a specific level until any of tehm could be enabled
> > We need to keep it simple. We can't have multiple domain levels or
> > it will quickly become a mess (test matrix will also explode).
> >
> > HTH,
> > Simo.
> >
>
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/16/2014 03:22 PM, Simo Sorce wrote: On Tue, 16 Dec 2014 11:33:41 +0100 Ludwig Krispenz wrote: Hi Simo, one thing is not quite clear to me: do you want a domain level per feature or a global domain level or both ? The Domain Level is global. I described a "Feature Version" that is published by feature. The Feature Versions just state what is available they do not determine what is the current overall Domain Level. Ok, just to confirm my understanding. - we have one domain level. - each (new) plugin or compoment has to define its minimal domain level and execute only features covered by this level - in addition, these plugins have to expose their (plugin) version on each server, allowing checks for setting the domain level For a single feature (eg topology management) it could be required that it is available on all servers, so it will be active only if it's domain level is set. But there could be another feature, independent of this one, it also could require to be installed on all servers, and wait until it's domain level is set. If we would only one domainlevel this would mean that all features need to be at a specific level until any of tehm could be enabled We need to keep it simple. We can't have multiple domain levels or it will quickly become a mess (test matrix will also explode). HTH, Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Tue, 16 Dec 2014 11:33:41 +0100 Ludwig Krispenz wrote: > Hi Simo, > > one thing is not quite clear to me: do you want a domain level per > feature or a global domain level or both ? The Domain Level is global. I described a "Feature Version" that is published by feature. The Feature Versions just state what is available they do not determine what is the current overall Domain Level. > For a single feature (eg topology management) it could be required > that it is available on all servers, so it will be active only if > it's domain level is set. But there could be another feature, > independent of this one, it also could require to be installed on all > servers, and wait until it's domain level is set. > If we would only one domainlevel this would mean that all features > need to be at a specific level until any of tehm could be enabled We need to keep it simple. We can't have multiple domain levels or it will quickly become a mess (test matrix will also explode). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On Tue, 16 Dec 2014 10:55:52 +0100 thierry bordaz wrote: > On 12/15/2014 11:01 PM, Simo Sorce wrote: > > Hello fellow developers, I added this new design: > > http://www.freeipa.org/page/V4/Domain_Levels > > > > It is a prerequisite for both the Replica Promotion design: > > http://www.freeipa.org/page/V4/Replica_Promotion > > and the Topology plugins design: > > http://www.freeipa.org/page/V4/Manage_replication_topology > > (Ludwig will change this to include the changes we have discussed > > in a previous phone call, and which involve mostly Domain > > Level/Domain Upgrades/migrations issues) > > > > As usual feel free to add as needed or comments and ask questions. > > > > Simo. > > > Hello, > > A new/old replica can join a topology with a given Domain level. > This replica may miss the requirements to be running at the > current Domain level. A replica that lacks the requirements will not be able to join. > Does the new comer replica need to follow a procedure before > joining ? Newer replicas will use the new installation method, one of the things that will be checked is if the Domain Level is supported by the replica. If the Domain Level is higher than what is supported then joining the replica will fail. > Is there a 'gate keeper' replica that would grant the > authorization to join ? Not necessary. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
Hi Simo, one thing is not quite clear to me: do you want a domain level per feature or a global domain level or both ? For a single feature (eg topology management) it could be required that it is available on all servers, so it will be active only if it's domain level is set. But there could be another feature, independent of this one, it also could require to be installed on all servers, and wait until it's domain level is set. If we would only one domainlevel this would mean that all features need to be at a specific level until any of tehm could be enabled Ludwig On 12/15/2014 11:01 PM, Simo Sorce wrote: Hello fellow developers, I added this new design: http://www.freeipa.org/page/V4/Domain_Levels It is a prerequisite for both the Replica Promotion design: http://www.freeipa.org/page/V4/Replica_Promotion and the Topology plugins design: http://www.freeipa.org/page/V4/Manage_replication_topology (Ludwig will change this to include the changes we have discussed in a previous phone call, and which involve mostly Domain Level/Domain Upgrades/migrations issues) As usual feel free to add as needed or comments and ask questions. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New/Updated FreeIPA design pages
On 12/15/2014 11:01 PM, Simo Sorce wrote: Hello fellow developers, I added this new design: http://www.freeipa.org/page/V4/Domain_Levels It is a prerequisite for both the Replica Promotion design: http://www.freeipa.org/page/V4/Replica_Promotion and the Topology plugins design: http://www.freeipa.org/page/V4/Manage_replication_topology (Ludwig will change this to include the changes we have discussed in a previous phone call, and which involve mostly Domain Level/Domain Upgrades/migrations issues) As usual feel free to add as needed or comments and ask questions. Simo. Hello, A new/old replica can join a topology with a given Domain level. This replica may miss the requirements to be running at the current Domain level. Does the new comer replica need to follow a procedure before joining ? Is there a 'gate keeper' replica that would grant the authorization to join ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
