On 05/11/2015 06:44 PM, Jan Cholasta wrote:
well, the design all over talks about domain levels, the entry is
specified as cn=domainlevel, .... so the discussion is questioning the
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:
IIRC, that was the point. To have this value in a single LDAP
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):
as already discussed in December , we will need to
in FreeIPA 4.2 to make sure we can manage the replication
I created a ticket for this feature  and linked it with
proposed scope for the feature is written in the ticket
would work on this.
The first consumer is Ludwig's topology plugin. Seeing
, I suspect he chose a different format (major/minor)
value, but as we discussed in , it will rather be a
only when needed. This is something for Tomas and Ludwig to
I am not sure if Custodia work will need this, maybe the new
ipa-replica-install would just check if Custodia is there
on Domain Levels... we will see.
The design page does not list the actual API, but I expect
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
property of a "domain" object.
I think the point here was that the Domain Level is a separate
just that value. So the naming seemed pretty self-explanatory
That seems to me like an implementation detail rather than
which to model the API. (Come on, singleton object with a single
other settings, so that components can simply "watch" this
syncrepl on it, without receiving false positives (as they would
example "config-*" object).
OK, so it indeed is just an implementation detail - if it was
to watch just a single attribute of an entry, it could be stored
meaningful location, but it's not, so it can't.
It is perfectly possible with SyncRepl protocol.
+1 for domainlevel - there is no and most likely won't be a
With using just "domain-*" we are blocking ourselves for the
"Domain" object shows up.
I don't see why it should.
Anyway, I don't have a strong opinion on this, except I like
I liked the raise more as it does not give people the hopes that
can be lowered once it was raised :-)
I like "set" because it is very explicit - "raise" not so much, it
mean "raise to specific value" or "raise by specific value" and
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
because there is only one realm but multiple domains in the realm.
That depends on the definition of "domain" :-) But I think "realm
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
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code