* Steve Gonczi <[email protected]> [2010-03-18 15:51]: > I am not entirely thrilled by having to restart the importer a 100 > times for 100 manifests, instead of delivering the 100 manifests, and > then running the importer once, but, OK, I can live with that.
The set of actuators is coalesced by svc: FMRI. So 100 manifest deliveries results in one restart of manifest-import. This restart is issued after all actions (i.e. file deliveries) have completed. > I fail to see this paradigm working for all use cases of restarting > "services, other than the importer". > > I posit that an initial install is different from an update. > > All component files need to be deployed before a service can be reasonably > fired up > the first time, so restarting the service upon deploying each file clearly > does not work. Solved by coalescing. > One solution is attaching the service start/restart to some specific > file, preferably the one that is deployed last. But this flies in the > face of the "update" use case which requires a service restart if > _any_ of the components changed. Solved by coalescing. > There could also be transactional issues on update. Say, I have > multiple files making up a service: an executable, a configuration > file, and a database. I am switching to a new db format so I have > to update all 3 components before I can restart the service. Solved by coalescing. > My installer has to handle the "garden variety" update (where only one of the > files changes) > as well as a "major revision" update, the latter being what I described above. > > The answer to my initial question, > > "Why can I trigger a service restart whenever I am good and ready, > independently > of any file changes" seems to be: > > "Because the TAO of IPS says so". If you wish to have an always-fired actuator, deliver a file that changes every version update, and place the actuator on that file action. > It seems to me: > > Service restarts cannot be reasonably tied to any specific file's deployment, > neither can they > be tied to every component file's deployment. Seems like catch 22. (I don't think we're in a paradox here: place the actuators on every appropriate file or change an actuator-decorated file every version.) > A standalone service restart action would solve the problem, perhaps > with a file or wild carded list , saying "if any of these files > changed, trigger a service update now". But the latter is just an > optimization. > > This would allow us to control the pesky timing of service restarts, > and cover all use cases. (Admittedly at the expense of perhaps > triggering an unnecessary service restart at times. Is that so bad? > Seems to be OK to restart the manifest importer for each deployed > manifest.. ) There's no timing issue, as actuators happen after all actions. And we don't have the superfluous restarts because of actuator coalescing. > I am trying to make the case, that it would be useful to control the exact > place a service restart > happens during an install. > > If I am missing key piece of functionality that can covers the use cases > above, please > show me the TAO way. Enlightenment? - Stephen * We haven't talked about the inner mysteries of smf(5) at all: are you delivering a meaningful default configuration so that your service instance can be enabled by default? _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
