* Steve Gonczi <[email protected]> [2010-03-17 20:55]: > Greetings, > > > I would like to gain a better understanding of the service manipulation > actuators. > > It looks to me, there is usually one actuator attached to some file action. > > I do not understand why an actuator can not just be run by itself.
Not all actions are delivered in an update of a package: unchanged actions won't be part of the plan. > e.g.: > > I deploy a set of service xml-s, and each one (or, myb just the last one) > features the importer restart_fmri actuator, so > they are imported by the time the I am done with my "file" actions. > > At this point, it would make sense to trigger the service restart_fmri (say, > via wildcard) > to restart / start all the services I have just deployed. > > At this point, the action I want to perform is not tied to any specific > file's deployment. > (All my file deployments are all done at this point) > > The man page does not spell out all the details, e.g.: can I use multiple > actuators per action? > Should I perform some bogus file action, such as re-setting permissions on an > arbitrary file > I already deployed so that I can run the service restart actuator? > That would feel a bit awkward, maybe there is a better way. > > So why do I need a file action to hang the actuator on? 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. I believe the only option we've thought about here would be an aliasing layer that would classify an action as associated with one or more related properties. Since that mostly works out to savings on characters typed, so far we've attacked that as extensions to the importer or to the publication and manifest manipulation tools. - Stephen -- [email protected] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
