On 5/31/2016 4:24 AM, Ade Lee wrote: This is a bit complex, but here's my initial thoughts: 1. I think we need more fine-grained trackers due to differences in how the DS contents are shared and replicated. Please take a look at this page: http://pki.fedoraproject.org/wiki/DS_Deployment_Scenarios a) There should be a separate tracker for DS schema (e.g. cn=schema,cn=trackers) since the schema is shared by all backends in the same DS instance (unless the subsystems use separate DS instances) and it's replicated to all clones. b) There should be a separate tracker for DS configuration (e.g. cn=config,cn=<DS hostname & port>,cn=trackers) since the configuration is shared with all backends in the same DS instance (unless the subsystems use separate DS instances), but it's not replicated to other clones. c) There should be a separate tracker for each subsystem subtree (e.g. cn=ca,cn=subtrees,cn=trackers) since the subtree is not shared with other backends, but it's replicated to all clones. d) There should be a separate tracker for each subsystem indexes (e.g. cn=ca,cn=indexes,cn=<DS hostname & port>,cn=trackers) since the indexes are not shared with other backends and they are not replicated to other clones. 2. I don't think global updates have to necessarily happen before local updates. The upgrade scripts should have their own sequence number to allow flexible execution order. The version numbers stored in the trackers should be independent of each other, but the upgrade scripts can enforce certain dependency. For example: 01-UpdateSchema 02-UpdateSubtreeToUseTheNewSchema Script #1 will do something like this: if schema.version < MIN_SCHEMA_VERSION: update_schema() Script #2 will do something like this: if schema.version >= MIN_SCHEMA_VERSION: update_subtree() So if the schema was already updated while upgrading another subsystem, the schema will not be updated again since the version number may already meet the minimum requirement. 3. Although we don't have a top-level DN now, different PKI subsystems using the same DS instance can share the same trackers stored in one of the subsystem subtree. The base DN of the trackers can be stored in a file in each PKI instance/subsystem, so it can be customized depending on the deployment scenario. When we have the top-level DN in the future, the trackers can be moved there too. 4. In the future there we might want to keep track of the optional security upgrades as well: https://fedorahosted.org/pki/ticket/1135 As shown in the example, at some point we might want to remove obsolete algorithm (e.g. SHA1withRSA), but we cannot do that automatically since some people might still depend specifically on it. So these types of upgrades should be optional, they should not block other upgrades, and the server should continue to function even without these upgrades. However, we need to keep track of them to remind people that in the future they will be required to do the upgrade. This can be done by adding tracking entries under one of the above trackers depending on the scope. For example: cn=Remove SHA1withRSA from caAdminCert profile, cn=ca,cn=subtrees,cn=trackers assuming the profiles are in LDAP, or cn=Remove SHA1withRSA from caAdminCert profile, cn=ca,cn=config,cn=<DS hostname & port>,cn=trackers if the profiles are still stored in locally in the CA subsystem that uses the above DS instance. Nothing to change in the design, but we just need to make sure this can be done in the future. -- Endi S. Dewata