Re: [Freeipa-devel] Domain Level feature kick-off
On 05/06/2015 09:29 AM, Martin Kosek wrote: Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. the topology plugin also accepts a single numerical value, eg 3. It will internally parse this to 3.0 and use this. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER Makes sense? [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html [3] https://fedorahosted.org/freeipa/ticket/5018 [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html -- 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 feature kick-off
Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. Makes sense? [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html [3] https://fedorahosted.org/freeipa/ticket/5018 [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html -- 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 feature kick-off
Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. -- 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 feature kick-off
On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) -- 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 feature kick-off
On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. Makes sense? [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html [3] https://fedorahosted.org/freeipa/ticket/5018 [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html -- 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 feature kick-off
On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. +1 for set -- 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 feature kick-off
Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. -- 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 feature kick-off
Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. +1 for set -- 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 feature kick-off
On 11.5.2015 16:36, Martin Kosek wrote: On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. It is perfectly possible with SyncRepl protocol. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. So call it 'functional level' :-) -- 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 feature kick-off
Dne 11.5.2015 v 18:03 Ludwig Krispenz napsal(a): On 05/11/2015 05:42 PM, Petr Spacek wrote: On 11.5.2015 16:36, Martin Kosek wrote: On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. It is perfectly possible with SyncRepl protocol. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. So call it 'functional level' :-) This thread is about implementing the design provided in Simo's domain level design page, we had discussed this before, do we really need to iterate it again ? I don't think anyone is actually suggesting to make changes to the design. Right? -- 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 feature kick-off
On 05/11/2015 06:44 PM, Jan Cholasta wrote: Dne 11.5.2015 v 18:03 Ludwig Krispenz napsal(a): On 05/11/2015 05:42 PM, Petr Spacek wrote: On 11.5.2015 16:36, Martin Kosek wrote: On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. It is perfectly possible with SyncRepl protocol. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. So call it 'functional level' :-) This thread is about implementing the design provided in Simo's domain level design page, we had discussed this before, do we really need to iterate it again ? I don't think anyone is actually suggesting to make changes to the design. Right? well, the design all over talks about domain levels, the entry is specified as cn=domainlevel, so the discussion is questioning the design -- 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
