[Freeipa-devel] [PATCH] move replication topology to shared tree

[Simo Sorce]

On Fri, 10 Oct 2014 17:52:15 +0200
Ludwig Krispenz <lkrispen at 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).

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.

> - 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.


-- 
Simo Sorce * Red Hat, Inc * New York