[Freeipa-devel] Domain Level feature kick-off

[Ludwig Krispenz]

On 05/11/2015 06:44 PM, Jan Cholasta wrote:
> 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?
well, the design all over talks about domain levels, the entry is 
specified as cn=domainlevel, .... so the discussion is questioning the 
design