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

[Ludwig Krispenz]

On 10/10/2014 06:21 PM, Simo Sorce wrote:
> 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).
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.
>
>