[Freeipa-devel] topology management question

Ludwig Krispenz lkrispen at redhat.com
Thu Dec 4 13:33:09 UTC 2014


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.

Thanks,
Ludwig




More information about the Freeipa-devel mailing list