[Freeipa-devel] Domain Level feature kick-off

[Ludwig Krispenz]

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