On 10/30/2015 10:42 AM, Martin Kosek wrote:
On 10/27/2015 04:40 PM, Ludwig Krispenz wrote:

On 10/27/2015 03:54 PM, Petr Vobornik wrote:
Both tools serve primarily for managing replication agreements and
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
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.

Note that people are used to use "-v" switch to show status of these
agreements. There would need to be a replacement for this functionality
to get rid of this command.

I always forgot about this option - from help it's not clear which commands supports it.

Yes, this implies that it should remain enabled, till we have the functionality in topo plugin.

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
to be centrally managed. Mainly because the preferred alternative is

2 may be a good choice, but we first need to find the alternative for
above. I do not think deprecating a list is a "must" for 4.3.


=== 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
--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
the state of specific agreements.

Can topologysegment-reinitialize simply wait? The behavior and related
options could be similar as with automember-rebuild.

Then we risk that CLI will timeout, same issue is in automember-rebuild and migrate-ds (there is a ticket for improving long running tasks).

I am wondering if topologysegment-reinitialize is not too low level.
Normally, the problem you are solving is that some of your master is out
of sync and cannot be fixed. Then you want to have some command to
re-intitialize *the master*, with the command potentially picking the
best topologysegment to be used.

It is quite low-level. That is also one of the reasons why I didn't put it to Web UI.

=== force-sync ===
no change yet

Currently done by setting nsDS5ReplicaUpdateSchedule attribute of repl.

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

Change in DS to support some of the Topology functionality is tricky. Is
this a blocker for releasing 4.3 with DL 1?

I don't think so.

Where I am coming from is that if Topology functionality depend on a DS
function, we cannot be sure that the Topology call works for all
masters. And I do not think we want to release DL 2 to support also this

We don't. We need some general approach for this. Every time we will add some new functionality to topology plugin or fix a bug there this very question will be raised again.

The simplest thing to do is have it enabled so the servers which don't support it will still have a usable method.

IMO if we want to preserve the possibility then the long-term
solution is to
move it to topology plugin.

Yes, but see above.

=== 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"
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
admin must get the info in cn=replica,cn=$SUFFIX,cn=mapping

We have a ticket to automate it:

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.

Would be nice to be moved to Topology. But same as above, we should
think if the change breaks the DL 1 or the fact that some of the servers
has the patch and some don't do not break anything.

=== dna(next)range-{show|set} commands
No change in 4.3.

Long term solution is to make it centrally manageable. Not sure if by
plugin or something else.

Currently, this configuration is set in cn=config. So here are 2 ways -
enhance Topology plugin or have some other Config Sync related plugin.

== ipa-csreplica-manage ==
This tool manages only CS replication agreements.

Yes. I think we want to stop using it completely in 4.3 in order to
really simplify CS management:

=== list ===
Not needed. We have `ipa server-find` and `ipa topologysegment-find

Should be disabled, add to #5405

Yes, but also consider the "-v" option question above.

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

Yup, looks like server-add-role type of command.

== Conclusion ==
ipa-csreplica-manage could be abandoned in 4.3 which plays well with
"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
in 4.3. This can change in a future. Same situation with DNA ranges

There is no future plan for winsync agreements and ipa-replica-manage
remain solely for this purpose in environments with managed topology.
yes, and we could rename it to ipa-winsync-manage

+1, that sounds as the end-game we want.

Petr Vobornik

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

Reply via email to