[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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


And in BC case, `ipa-replica-manage --force` would call `server-del


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

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.


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

Petr Vobornik

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]