[Freeipa-devel] server_del (re)implementation in domain level 1 topology management

[Petr Vobornik]

On 03/17/2016 03:17 PM, Martin Babinsky wrote:
> On 03/17/2016 02:55 PM, Petr Vobornik wrote:
>> On 03/17/2016 02:39 PM, Martin Babinsky wrote:
>>> Hi list,
>>>
>>> I would like to discuss the merge of `del_master_managed()` function
>>> from `ipa-replica-manage` command into the server_del API call that is a
>>> part of the managed replication topology design update[1] (see also the
>>> corresponding upstream ticket [2]).
>>>
>>> Before I head down into coding I want to be sure that everyone is one
>>> the same page regarding the expected use-cases which govern the API
>>> design.
>>>
>>> IIUC, there are two main uses of the new functionality according to
>>> design document:
>>>
>>> 1.) run 'server_del' when 'ipa-replica-manage del' is run in
>>> domain-level 1
>>
>> Right, this is for backwards compatibility(BC).
>>
>>>
>>> 2.) during 'ipa-server-install --uninstall', 'server_del' should be
>>> called on one of remote masters to remove the uninstalled server from
>>> the managed topology
>>>
>>> What I didn't get from the design document is whether the method should
>>> have some kind of 'force' option which should bypass all topology
>>> connectivity checks. Currently both `ipa-replica-manage del` and server
>>> uninstaller have options which will force the removal even if it
>>> disconnects the topology ('--force' in the former,
>>> '--ignore-disconnected-topology' in the latter).
>>
>> I would say that uninstaller should do checks in validate method
>> therefore the subsequent `server-del` doesn't need to do it again but it
>> shouldn't harm. I.e. it should follow what the user specified. If user
>> wants to skip (--ignore-d..-t..) then skip. If not then it will fail in
>> validate method.
>>
>> Only issue might be error state where servers have different picture of
>> the topology.
>>
> If the view of the topology is not self-consistent then you have plenty
> of other issues to take care of and that may include some forced removal
> and recreation of nodes.
>
>>>
>>> I guess the 'server_del' method should inherit this flag so that we
>>> retain the original functionality (for better or worse). I propose to
>>> name this option 'ignore_topology_disconnect' because it is more
>>> descriptive than plain 'force'.
>>
>> +1
>>
>> And in BC case, `ipa-replica-manage --force` would call `server-del
>> --ig..-d..-t...`
>>
> Yes.
>>>
>>> I would also like to ask whether 'server_del' (which is currently
>>> NO_CLI) should be usable also from command line.
>>
>> IMO yes, it should mostly as a couterpart of `ipa-replica-manage --force
>> --clean`
>>
>> Which bring us to --clean option and what it should do...
>>
> According to the design, '--clean' should be used as a cleanup of
> leftovers after deleted servers. How I image it from the implementation
> point of view is that when '--clean' is specified and the server was
> already deleted, the NotFound error raised from the framework should be
> ignored and the code should continue in clean up. (I assume that
> segment/service/dns cleanup will be done in post_callback portion and
> the topology connectivity/sanity checks in the pre_callback).

When thinking about it, clean could be a separate command which would be 
called internally in post callback of server-del. It would reduce the 
number of ifs in server-del and simplify it in general. It would work 
only if server entry doesn't exists.

> That means that '--clean' has no additional effect when the server exists.

Right

>>>
>>>
>>> [1] http://www.freeipa.org/page/V4/Manage_replication_topology_4_4
>>> [2] https://fedorahosted.org/freeipa/ticket/5588
>>>
-- 
Petr Vobornik