On Sun, 07 Dec 2014 10:25:06 -0500
Rob Crittenden <rcrit...@redhat.com> wrote:
> Simo Sorce wrote:
> > On Thu, 04 Dec 2014 14:33:09 +0100
> > Ludwig Krispenz <lkris...@redhat.com> 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
> I had another, sort of unrelated thought about this, thinking about
> deleting servers.
> What happens if a replication conflict entry gets added?
This would happen in case a provisioning system tries to instantiate 2
servers with the same name at the same time talking to different
> While both exist I imagine that the actual agreement would reflect
> whichever entry is processed last. Probably not the end of the world.
> But how do you remove the conflict entry without also potentially
> deleting that master?
It should probably delete both, the domain would be pretty messed up
anyone and we have no easy way to know which of the 2 is part of the
domain and which one has all replication severed due to their keys
being overwritten by the other server ones.
I guess the only thing we can reasonably do is to make recommendations
on how to deal with replicas deployments to avoid this case and
instructions on how to remove remnants entries if any.
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list