Re: [Pki-devel] replication of new/modified profiles

On Tue, 2014-07-01 at 12:42 +1000, Fraser Tweedale wrote: The problem with the above proposal is one of migration. Customers are used to both creating new profiles and modifying existing profiles to suit their needs. If we go along with this mechanism, we would have to tell these customers that they would need to rename their existing customized profiles (and update all the relevant clients etc.) There is another problem, and that is that it is not clear that we want updates to the default profiles to be propagated to existing instances. I have looked at the profiles and there have been only a handful of changes over the last 7 years. Those changes include things like updating the default signing algorithms or the default validity. More likely than not, admins would prefer that we not change the behavior of profiles in existing instances underneath them. The changes that I have found are all behavioral - and therefore things that admin can opt out of -- or would prefer to do on their own schedule. There have been no structural changes. If there are structural changes, then we need to (and can) provide an upgrade script which would run with the automatic upgrade. An example of this would be a schema upgrade as we sort out how to represent profiles in LDAP. So, I think we should do the following: 1. Continue to provide the system profiles in files. These files will be parsed and stored in LDAP when an instance is created. 2. All profiles for an instance should live in LDAP. This makes it simple - no need to check to see if a profile is in LDAP or files or both, and which has priority etc. Tools will be provided to manage/ create/delete profiles etc. 3. Updates to system profile files will not affect the existing LDAP profiles. We can provide update scripts or manual instructions for admins to run when they opt to do so. This will be for behavioral changes. 4. Structural changes will be done using upgrade scripts using the database upgrade mechanism. This framework is something that we had planned to do already in 10.3. We already have a model on how to do this in our current upgrade framework. I would prefer to see if we could design something more fine grained at first, rather than assuming an upgrade. If nothing else, you will need to separate out whether the profile is visible and enabled and by whom. Agreed. I think this can be a later development.