Hello, I do appreciate the responses, and the conceptual elegance of actuators.
As I am thinking about the possible use cases, I am unsure if they are all covered. I must admit I am new to writing IPS installers, so I may be missing something. Le's see if I get the concept, based on Steve Hahn's recent explanation (quote): > So, if none of your service manifests was changed in an update, the > actuator shouldn't be run. That means that the actuator isn't > independent of the actions that deliver the manifests. Since a subset > of the manifests may have changed, the actuator must be present on > each file action that may be delivered in a hypothetical update. To paraphrase: "There should be a service actuator on each file action that may get updated, if the file impacts a service. This is because individual files may or may not end up getting deployed, so tying an actuator to a specific file may cause a service restart being missed on update, if that specific file does not get deployed." I can see this paradigm working reasonably well for service manifests and the associated restart of the manifest importer service. 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. 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. 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. 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. 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". 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. 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.. ) 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. On Mar 17, 2010, at 8:20 PM, Shawn Walker wrote: > On 03/17/10 05:06 PM, Danek Duvall wrote: >> Steve Gonczi wrote: >> >>> It looks to me, there is usually one actuator attached to some file action. >> >> True, though that needn't be the case. You can have more than one actuator >> attached to an action. An actuator can be attached to any action, not just >> file. > > Although, just to be clear, more than one value for the same actuator on the > same action is not currently supported. Such as: > > action disable_fmri="..." disable_fmri="..." > > Cheers, > -- > Shawn Walker Steve Gonczi [email protected] _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
