[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
we already have ipa-replica-manage and ipa-csreplica-manage, and
- I did'n want to integrate the topology management into both and 
duplicate code
- there is much change on the way to refactor the ipa commands, to move 
code into libraries, to expose to openLMI
and I have no clear picture yet how this will look like, so I thought 
implementing the management command as subclasses of admintool would be 
a good starting point - I do not insist that ipa-topology-manage will 
survive as a command in the end, but I also do not want to mess with 
ipa-replica-manage and ipa-csreplica-manage now, when these changes also 
probably would have no future.
> e
>
>> 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.
>
>