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.

Simo.

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 on that. We can simply our life by making the initialization a special admin initialized operation for the situations when we upgrade from earlier versions. 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.

I finally agree, especially after having done some experiments with a rapid prototype. 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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to