[Freeipa-devel] Move replication topology to the shared tree

[Rich Megginson]

On 06/02/2014 08:38 AM, Simo Sorce wrote:
> On Mon, 2014-06-02 at 10:08 -0400, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> However we may want to be able to mark a topology for 'multiple' sets.
>>> For example we may want to have by default the same topology both for
>>> the main database and for the CA database.
>> I think we should store them separately and making them the "same" would
>> be applied by a tool, but the data would just reflect the connections.
>>
>> I was thinking the object DN would contain the LDAP database name (or
>> some rough equivalent), so we would store the IPA connections separate
>> from the CA connections.
> Ok, we can debate about this, maybe we simply have a flag in the
> framework that 'links' two topologies and simply replicates any change
> from one to the other.
>
> The only reason I had to 'mark' stuff in a single topology in order to
> share it is that this way any change is atomic and the 2 topologies
> cannot diverge, as the objects are the same, if we think the chance of
> divergence is low or that it is not important because the topology
> plugin will always prevent disconnected states anyway then we may avoid
> it, and let the framework try to keep topologies in sync and just loudly
> warn if they somehow get out of sync (which will happen briefly every
> time replication of the topology objects happens :).
>
>>>> ad 2] the data required are available in the replicationAgreement (and
>>>> eventually replica) entries, but the question is if there should be a
>>>> 1:1 relationship to entries in the shared tree or a condensed
>>>> representation, if there should be a server or connection oriented view.
>>> My answer is no, we need only one object per connection, but config
>>> entries are per direction (and different ones on different servers).
>> We also need to store the type, MMR, read-only, etc, for future-proofing.
> Store where ?
>
>> One entry per connection would mirror what we have now in the mapping
>> tree (which is generally ok). I wonder if this would be limiting with
>> other agreement types depending on the schema we use.
> My idea is that on the connection object you have a set of attributes
> that tells you how replication happen.
>
> So normally you'll have:
> dn: uuid?
> objectclass: ipaReplicationTopologySegment
> left: master-X
> right: master-Y
> direction: both || left-right || right-left (|| none ?)
>
> If we have other special types we change direction accordingly or add
> another attribute.
>
>>> We already have the list of servers, so we need to add only the list of
>>> connections in the topology view. We may need to amend the servers
>>> objects to add additional data in some cases. For example indicate
>>> whether it is fully installed or not (on creation the topology plugin
>>> would complain the server is disconnected until we create the first
>>> segment, but that may actually be a good thing :-)
>> Not sure I grok the fully installed part. A server isn't added as a
>> master until it is actually installed, so a prepared master shouldn't
>> show here.
> Uhmm you may be right, if we can make this a non-problem, all the
> better.
>
>>>> Next question: How to handle changes directly done in the dse.ldif, if
>>>> everything should be done by the topology plugin it would have to verify
>>>> and compare the info in cn=config and in the shared tree at every
>>>> startup of the directory server, which might be complicated by the fact
>>>> that the replication plugin might already be started and repl agreemnts
>>>> are active before the topology plugin is started and could do its work.
>>>> (plugin starting order and dependencies need to be checked).
>>> Why do we care which one starts first ?
>>> We can simply change replication agreements at any time, so the fact the
>>> replication topology (and therefore agreements) can change after startup
>>> should not be an issue.
>> Someone could delete an agreement, or worse, add one we don't know
>> about. Does that matter?
> Someone can do this at any time after startup, so we already need to
> handle this, why should it be a problem ?

It shouldn't be a problem for replication, since everything is dynamic.


>
> However I agree we want to avoid churn, so to answer to Ludwig as well I
> guess we just want to make sure the topology plugin always starts before
> the replication plugin and amends replication agreements accordingly.

+1 - I think this will avoid some problems.

>
>> What happens to values in the mapping tree that aren't represented in
>> our own topology view?
> I think we should ignore them if they reference a machine that is not a
> recognized master, I guess the main issue here is a case when a master
> got deleted and somehow the cn=config entry was not and we end up with
> an orphan agreement that the topology plugin initially created but does
> not recognize as its own.
> I see 2 options here:
> 1) We ignore it, and let the admin deal with the issue
> 2) We mark agreements with a special attribute that indicates they have
> been generated by the topology plugin, so the plugin can delete any it
> does not recognize as currently valid. The only problem here is initial
> migration, but that is not a huge issue IMO, the topology plugin may
> simply recognize the two sides of an existing agreement are 2 ipa
> masters, and just take over those entries.
>
> [..]
>
>> So when we do the migration to this version some script will be needed
>> to create the initial topology from the agreements. Could we have a race
>> condition?
> If we do the takeover thing I describe above maybe not ?
>
>>> I really do not want to touch the replication plugin. It works just fine
>>> as it is, and handling topology has nothing to do with handling the low
>>> level details of the replication. To each its own.
>>> If other deployments want to use the topology plugin, we can later move
>>> it to the 389ds codebase and generalize it.
>> My memory is fuzzy but I think that restarts are required when
>> adding/deleting agreements. Is that right? What implications would that
>> have for this?
> We create (and change) agreements on the fly w/o ever restarting the
> server right now, so I would say not ?

Correct.  Replication configuration is dynamic.

>
> Simo.
>