>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.

And has caused all services to spring their own "at first boot
finish installation" stuff: postrun, fc-cache, etc.

This screams "hole in architecture, must fix" to me.

>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.

The whole "manifest import" thing has issues with upgrades also;
other services are potentially started before manifests are
imported which declare dependencies.

>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.

There's another secondary issue: currently, when a Solaris developer
removes a service, the onus is on them to clean up all vestiges
in the repository.  Somehow, this feels wrong.

Casper

Reply via email to