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

[Petr Vobornik]

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

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

+1

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

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

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

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


-- 
Petr Vobornik