[Freeipa-devel] Domain Level feature kick-off

[Petr Vobornik]

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. 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.

+1 for set
-- 
Petr Vobornik