[Freeipa-devel] [draft] Fate of ipa-replica-manage and ipa-csreplica-manage tools

[Ludwig Krispenz]

On 10/27/2015 03:54 PM, Petr Vobornik wrote:
> Both tools serve primarily for managing replication agreements and 
> replicas. ipa-replica-manage also manages winsync agreements and DNA 
> ranges.
>
> FreeIPA 4.3 will introduce managed topology which affects these tools.
>
> Let's go trough all sub-commands of both tools and decide what is the 
> fate of them/how they should be replaced. Comments are welcome.
>
> In text, term 'disable' means: print an error message with help what 
> is the new alternative.
>
> For domain level == 0 all sub-commands should behave the same way as 
> before. Proposals are for domain level 1 if not stated otherwise.
>
> == ipa-replica-manage ==
> === list ===
> Lists all IPA server or replication agreements of a specific IPA 
> server including winsync agreements.
>
> Server list is replaced by
>   ipa server-find
> Replication agreements by:
>   ipa topologysegment-find realm
>
> I see following paths:
> 1. do not change (current state)
> 2. list only winsync agreements - IMO it will be easier to maintain
>
> If winsync was not in play we could 'disable' it but winsync is not 
> planned to be centrally managed. Mainly because the preferred 
> alternative is trust.
>
> === connect ===
> Allow for winsync, disable for REALM agmts. (current state)
>
> === disconenct ===
> Allow for winsync, disable for REALM agmts. (current state)
>
> === del ===
> (current state)
> With domain level 0:
> - removes replica and repl. agmts for REALM suffix and winsync
> With domain level 1:
> - removes replica entry and therefore repl. agmts for all 
> suffices(REALM, CS)
> - ensure last services, e.g. sets renewal master
> - does additional cleanup
>
> I'm not aware of any operation which needs directory manager. IMO it 
> can be moved to API in future release(e.g. 4.4), especially if 
> ipa-server-install --uninstall is modified to do most of the cleanup.
>
> === re-initialize ===
> Not changed.
>
> Can be disabled (long-term solution)
>
> Same capability is in topologysegment_reinitialize API command. The 
> only difference is that no API command shows state of the pending 
> operation. Should we transform presence of 'start' and 'stop' in 
> nsds5beginreplicarefresh;left|right attribute into an output of 
> topologysegment_show, e.g.: 'initialization in progress', 
> 'cancellation of re-initialization requested'.
yes, something like this would be possible,
maybe this can be part of the replication monitoring work, allowing to 
query the state of specific agreements.
>
> === force-sync ===
> no change yet
>
> Currently done by setting nsDS5ReplicaUpdateSchedule attribute of 
> repl. agreement.
>
> 1. Is it required?
> 2. Should the functionality be transferred to topologysegment/topology 
> plugin?
> 3. Is current approach good?
in fact it is a hack, it uses the fact that a change in the replication 
agremeent will trigger a fresh start of the protocol thread. It woul be 
more clean to have "sendupdatesnow" attribute or as a value of the 
refresh attribute, would require a change in DS
>
> IMO if we want to preserve the possibility then the long-term solution 
> is to move it to topology plugin.
yes
>
> === list-ruv, clean-ruv, abort-clean-ruv, list-clean-ruv ===
> Commands manages clean-all-ruv operations on REALM suffix. 
> ipa-csreplica-manage doesn't have these commands #4987. These 
> operations are meant for removal of dangling ruvs but they can also 
> remove "correct" RUV which is not desired.
>
> The UX is not the best because if replica still exists it won't tell 
> the admin what is the correct RUV and which are the dangling one(s) 
> and therefore admin must get the info in 
> cn=replica,cn=$SUFFIX,cn=mapping tree,cn=config
>
> We have a ticket to automate it: 
> https://fedorahosted.org/freeipa/ticket/5411
>
> Is it possible to manage it in topology plugin in centralized manner?
>
> I see $5411 as short-term solution for 4.3 or 4.4. + 
> {list|clean|abort-clean-list-clean}-ruv sub-commands should be 
> extended to work with all suffices.
>
> Long term solution not in 4.3 is to move it to topology plugin.
>
> === dna(next)range-{show|set} commands
> No change in 4.3.
>
> Long term solution is to make it centrally manageable. Not sure if by 
> topo plugin or something else.
>
>
> == ipa-csreplica-manage ==
> This tool manages only CS replication agreements.
>
> === list ===
> Not needed. We have `ipa server-find` and `ipa topologysegment-find 
> ipaca` commands.
>
> Should be disabled, add to #5405
>
> === connect and disconnect ===
> Replaced by `ipa topologysegment-{add,del}` commands.
>
> disable #5405
>
> === del ===
> The work is done in `ipa-replica-manage del` therefore disable #5405
>
> === re-initialize ===
> Same as in ipa-replica-manage - can be disabled. No ticket yet.
>
> === force-sync ===
> Same as in ipa-replica-manage - decide what to do. No ticket yet.
>
> === set-renewal-master ===
> AFAIK it's only update in cn=masters so could be moved to API then 
> this could be disabled.
>
> The change is simple enough for changing in 4.3. No ticket yet.
>
> == Conclusion ==
> ipa-csreplica-manage could be abandoned in 4.3 which plays well with 
> topic "simplify management of CA replication agreements".
for domainlevel == 0 we need to keep it
>
> ipa-replica-manage is still needed for RUV handling and removal of 
> replicas in 4.3. This can change in a future. Same situation with DNA 
> ranges handling.
>
> There is no future plan for winsync agreements and ipa-replica-manage 
> can remain solely for this purpose in environments with managed topology.
yes, and we could rename it to ipa-winsync-manage