[Freeipa-devel] Domain Level feature kick-off

[Jan Cholasta]

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