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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
