[Freeipa-devel] Domain Level feature kick-off

[Jan Cholasta]

Dne 11.5.2015 v 18:03 Ludwig Krispenz napsal(a):
>
> 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 ?

I don't think anyone is actually suggesting to make changes to the 
design. Right?

-- 
Jan Cholasta