[Freeipa-devel] Domain Level feature kick-off

[Martin Kosek]

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
>