I'm proposing the addition of an upgrade method for each service to be a possible solution for various types of upgrade issues. Currently, updated services perform their customizations through adding commands into the /var/svc/profile/upgrade file which are executed after manifest-import completed. A quick look at /var/svc/profile/upgrade* file shows how much customization currently exists. Another example is those services that convert configuration parameters from *.conf files into the repository. Upon a reboot following an upgrade, the current recommended mechanism to migrate and preserve existing configuration into repository is to add "svccfg setprop" commands into /var/svc/profile/upgrade.
The use of /var/svc/profile/upgrade file requires a contract for all services. Can non-Sun services contract for the use of /var/svc/profile/upgrade? This /var/svc/profile/upgrade may get too cluttered and complicated over time as more and more upgrade customizations need to be done. The proposed upgrade method is an extension to the current SMF service definition. The upgrade method ONLY executes on the first reboot following the upgrade of that particular service(after manifest-import completes the import of the new service manifest). This service specific upgrade method allows us to deliver customized commands/work into a service specific method rather than a common file for all services. Third-party and non-Sun services can easily deliver their upgrade customization without having to establish contracts. I don't claim to have all the details figured out :^) but thought I should start the discussion. Would something like the proposed upgrade method make life easier for people? What problems may we encounter with this approach? Comments and suggestions are very much welcome. -tony
