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 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.
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.
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.
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)
+1.
=== 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.
Ok.
=== 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.
Can topologysegment-reinitialize simply wait? The behavior and related options
could be similar as with automember-rebuild.
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.
=== 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
Change in DS to support some of the Topology functionality is tricky. Is this a
blocker for releasing 4.3 with DL 1?
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 command.
IMO if we want to preserve the possibility then the long-term solution is to
move it to topology plugin.
yes
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" 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.
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 topo
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:
https://fedorahosted.org/freeipa/ticket/3053
=== list ===
Not needed. We have `ipa server-find` and `ipa topologysegment-find ipaca`
commands.
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 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
+1, that sounds as the end-game we want.
--
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
