I finally agree, especially after having done some experiments with a
If the topology plugin is started before the replication plugin and does
changes to the shared tree, these are not replicated.
If the topology plugin is started after the replication plugin I get a
failure in replication that no csn is assigned, and the startup of the
topology plugin fails.
These might be bugs to be resolved, but I think I will follow Dmitri's
scenario for now - improvements can come later
We already have several situations (CRL, DNSSEC, cert rotation) where
a single server has to do the job first and all the rest should rely
We can simply our life by making the initialization a special admin
initialized operation for the situations when we upgrade from earlier
So general topology plugin does not initialize anything automatically.
If we build a new deployment the ipa replica management tools will
drive the modifications as servers are added.
If it is an upgrade admin might go to IPA configuration and ray
build/rebuild topology. This will drop all segment information if
there is any and using master list from cn=masters connect to each
replica, query its replication agreements and create data for the
replicated tree. If some replica is not on line the operation will
report that replica can be connected and that topology is not complete.
I think this is acceptable for topology plugin to focus only on
keeping data in sync when replica management tools are invoked and mot
worry about initialization after migration.
we need to be careful on the process, I have an idea how it could work,
but need to think a bit more about it
I am all ears.
Freeipa-devel mailing list