On 12/18/2014 02:52 PM, Simo Sorce wrote:
On Thu, 18 Dec 2014 10:56:47 +0100
thierry bordaz <tbor...@redhat.com> wrote:
On 12/16/2014 05:44 PM, Simo Sorce wrote:
On Tue, 16 Dec 2014 10:40:20 -0500
Simo Sorce <s...@redhat.com> wrote:
On Tue, 16 Dec 2014 15:57:34 +0100
Ludwig Krispenz <lkris...@redhat.com> wrote:
On 12/16/2014 03:22 PM, Simo Sorce wrote:
On Tue, 16 Dec 2014 11:33:41 +0100
Ludwig Krispenz <lkris...@redhat.com> wrote:
Hi Simo,
one thing is not quite clear to me: do you want a domain level
per feature or a global domain level or both ?
The Domain Level is global.
I described a "Feature Version" that is published by feature.
The Feature Versions just state what is available they do not
determine what is the current overall Domain Level.
Ok, just to confirm my understanding.
- we have one domain level.
Yes.
Hello,
Domain level can only be increased. Can it interfere with the ability
of the admin to downgrade a software version ?
Yes it will interfere, but the domain level will never be automatically
raised, so the admin has time to do tests for normal functionality, and
can wait to raise the domain level if there are reports of issues with
newer functionality.
there is one more scenario I would like to clarify. If a new replica is
installed or a client promoted to a replica, this means th enew
installation of a DS instance, which for some time is not connected to
the rest of the topology until its shared date are initialized from an
existing server in the topology. After the total init is complete, it
can check the set domain level and act accordingly.
But how should it act before, assuming domain level 0, or should
admin/scripts set a temporary domain level in the neew server, even if
it will be overwritten later by replica initialization ?
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
