On 10/10/2014 06:21 PM, Simo Sorce wrote:
On Fri, 10 Oct 2014 17:52:15 +0200
Ludwig Krispenz <lkris...@redhat.com> wrote:
Hello,
this is the current status of my work on #4302, and there are a few
pieces still missing, eg the management command needs more input
checking and error handling, but
- I wanted to give people interested a chance to have a look again
and get feedback
- there came up the following questions I would like to get an
opinion.
First thing, I do not think we want a new command here.
If we need commands outside of the ipa framework they should be
integrated in the ipa-replica-manage tool.
But really one of the reasons to move data in the shared tree was that
we could grow native framework command to handle the topology so we can
manage the topology directly from the UI.
So I am not happy with ipa-tology-manage
when thinking how to move from an existing deployment with direct
management of replication agreement to the new way, there should not
be any intermediate disconnects, and if possible transition should be
made easy. So I think we should have defined a few modes of operation
for the plugin:
- initial/bootstrap [optional] - the plugin detects existing
agreements and transforms it to segments in the shared tree
This should not be optional imo, its the only way to do sane upgrades.
When the plugin starts it needs to check if there are replication
agreements with other freeipa servers (it should ignore anything else).
it is fine for me if it is not optional, I agree that it is needed for
smooth upgrades.
the reason that I brought this up is that I had the impression that it
is not wanted, that
configuration should be in full responsibility of an admin creating the
shared topology from
scratch.
If we agree that the shared topology should be populated from existing
agreements I'm happy, if not I would make it at least optional.
the problem to solve is, when does this auto generation stop ? I think
it should be done only once, at the initial startup of the plugin and not
allow to bypass the topology plugin later by stopping th eserver,
editing cn=config to add a new agreement and having it added at startup
to the shared tree,
so there shoul be some way to flag that the initial phase is done.
I'm not sure if this can and should be handled with naming conventions.
Then check if these agreements have been autogenerated (this should be
determined by new naming conventions for agreements in cn=config) or
if they are pre-existing, if they are pre-existing then new shared
entries will be generated in the shared tree.
Note: this upgrade thing could also be done in ipa-upgrade plugins, at
server upgrade time. Whichever is easier (main concern is if 2 servers
are upgraded at the same time replication conflicts may arise).
- pending - the plugin handles and propagates segments in the shared
tree, but does not enforce teh deletion or creation of replication
agreements
Not sure what you mean here, but I think that once the plugin is
active it should stay active and actively prevent manual changes to
automatically created replication agreements.
why I wanted this state had two reasons.
- Since the information in the shared tree is authoritative and if you
start to build the shared tree from scratch (if the above initialization
would not be done)
there is the problem that adding the shared topology is not atomic, one
segment is added, all others do not yet exist and other replication
agreements
would be deleted, in the best case replication is just interrupted. So I
was suggesting a pending mode, you can add/delete segments from the
shared tree, verify connectivity and then say go and let the shared tree
become authoritative.
- A similar problem arises when adding a new replica, we had decided to
leave ipa-replica-install untouched, so it will install a new server and
try to setup replication agreements between the server replica-prepare
was run and the new replica, but it would be rejected by the plugin when
it is enforcing new agreements to be generated only via shared config.
So temporariliy disable the authority of the plugin could help.
- active - directe management of replicatio agreements is rejected,
existing segments ond their modifications are applied
This should always be.
I did run my tests of the management command as directory manager
since admin did not have permissions to read plugin configuration in
cn=config,
Why would you need to access cn=config ?
All management should happen in the shared tree, moving to be able to
avoid directly touching cn=config and avoid the need for DM password is
one of the main reasons to do this work ...
I can add permissions, probably will also need permissions
for the part in the shared tree, so what is the expected operation
mode, which user needs access to the shared config data and
configuration ?
We need to introduce a role for "Replication Admins" and make the
admins group a member by default, then use normal permissions framework
to regulate access.
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
