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

[Martin Babinsky]

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

That means that '--clean' has no additional effect when the server exists.
>>
>>
>> [1] http://www.freeipa.org/page/V4/Manage_replication_topology_4_4
>> [2] https://fedorahosted.org/freeipa/ticket/5588
>>
>
>


-- 
Martin^3 Babinsky