Quoth Tony Nguyen on Mon, Feb 05, 2007 at 01:57:50AM -0700: > 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.
Well more generally services need to upgrade their configuration and SMF has placed developers between a rock and a hard place: on one hand we forbid reading the repository on a dead root, but on the other the proper upgrade hooks offered by the packaging system (preinstall & postinstall) are pre-reboot. Aside from the service functionality itself, the only post-boot hook we offer is the upgrade file, and we want to keep that private so we can get rid of it. So a developer could have his service upgrade its configuration when it starts (e.g., the start method), but then the service will accrete a bunch of upgrade functionality. And it's possible that the service should and will be started with less privilege than necessary to modify its configuration. An upgrade method would provide a per-service post-boot hook, which could be launched with separate privileges than the service itself. > 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? Timing. I think the upgrade method should be executed when the start method would ordinarily be executed, so that all of the dependencies are ready. Which begs the question of whether any developer would want his upgrade method to be executed sooner than when his service would start. I think the only reason to do that would be if the configuration were being consumed by other entities which could start earlier. I think in those cases the other entities should depend on the configuration owner anyway. Assuming we do that, what state do we report the service being in when its dependencies are met but we're executing the upgrade method? offline->online is all I can think of, though we may need more detail so that svcs -x can distinguish between "upgrade method running" and "start method running". I also wonder if we should be more general in deciding when the upgrade method needs to be run. Shouldn't it be executed if the user upgrades by manually pkgrm'ing and pkgadd'ing? I think we should require service developers to deliver a version number with their service and record it in the repository. Then we can execute the upgrade method whenever the version number changes. If we exposed the version number to the service developer, this would also make it much easier to tell what needs to be changed, since he could easily determine exactly which older version of the configuration is present. Or we could just execute the upgrade method every time the service starts, and let it decide whether anything needs to be done. Finally since the upgrade method might migrate the administrator's customizations, we should probably record that the upgrade method ran, and what the configuration was beforehand. I suppose snapshots can be used for the latter and a log message could be used for the former. David
