[Freeipa-devel] Domain Level feature kick-off

[Petr Spacek]

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