[Freeipa-devel] topology management question

[Rob Crittenden]

Ludwig Krispenz wrote:
> hi,
> 
> I just have another (hopefully this will end soon) issue I want to get
> your input. (please read to teh end first)
> 
> To recapture the conditions:
> -  the topology plugin manages the connections between servers as
> segments in the shared tree
> - it is authoritative for managed servers, eg it controls all
> connections between servers listed under cn=masters,
>   it is permissive for connection to other servers
> - it rejects any removal of a segment, which would disconnect the topology.
> - a change in topology can be applied to any server in the topology, it
> will reach the respective servers and the plugin will act upon it
> 
> Now there is a special case, causing a bit of trouble. If a replica is
> to be removed from the topology, this means that
> the replication agreements from and to this replica should be removed,
> the server should be removed from the manages servers.
> The problem is that:
> - if you remove the server first, the server becomes unmanaged and
> removal of the segment will not trigger a removal of the replication
> agreement
> - if you remove the segments first, one segment will be the last one
> connecting this replica to the topology and removal will be rejected
> Now, with some effort this can be resolved, eg
> if the server is removed, keep it internally as removed server and for
> segments connecting this server trigger removal of replication agreements
> or mark a the last segment, when tried to remove, as pending and once
> the server is removed also remove the corresponding repl agreements
> 
> But there is a problem, which I think is much harder and I am not sure
> how much effort I should put in resolving it.
> If we want to have the replication agreements cleaned up after removal
> of a replica without direct modification of cn=config, we need to follow
> the path above,
> but this also means that the last change needs to reach both the removed
> replica (R) and the last server(S) it is connected to. The bad thing is
> that if this change triggers a
> removal of the replication agreement on S it could be that the change is
> not replicated to R before the agreement is removed and is lost.
> There is no way (or no easy) way to know for teh plugin if a change was
> received by an other server, I was also thinking about some kind of
> acknowledge mechanism by doing a ping pong of changes, but the problem
> always is the same that one server does not know if the other has
> received it.
> And even if this would theoretically work, we cannot be sure that R is
> not shutdown and only the remaining topology is tried to be cleaned up,
> so S would wait forever.
> 
> My suggestion to resolve this (in most cases) is to define a wait
> interval, after the final combination of removal of a server and its
> connecting segment is received, wait for some time and then remove the
> corresponding replication agreements.
> 
> So I'm asking you if this would be acceptable or if you have a better
> solution.

As I understood the proposal, you receive change requests which are
validated and applied on the server that received them. This is going to
cause changes to be replicated. On servers that get these replicated
changes they simply apply the changes w/o applying the associated logic.
Blindly, in other words. Doesn't that make this problem go away?

rob