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

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to