Bart Smaalders wrote: > Bart Smaalders wrote: > >> A bit tricky in spots... note that the alternate versions >> of svcprop and svcadm invoked during testing are defined >> as part of the test procedure. >> >> - Bart >> >> > > It must be time to go home... here's the url: > > http://cr.opensolaris.org/~barts/triggers/ > > - Bart > > > General questions: Can any package affect any smf service in a permanent way? For example, if I get package foo, can it permanently disable my firewall/ip filter (for example), or enable telnet which wasn't previously enabled? Is it possible to deliver a new service which is started on installation?
It seems like an action can specify more than one actuator. What happens if it specifies several actuators for the same service? For example, it states it wants the same service refreshed, suspended, tmp suspended, and restarted? I think the test in t_actuators.py is getting at this, but I don't really understand why it produces the output it does. actuators.py: 39-70: Maybe brief comments explaining the purpose of overriding each method? 134: I'd probably prefer using a set here, rather than integer ordering, it might make the code easier to read and follow, but it's not a big deal Nit: 259-262: indentation looks wrong to me Roughly what would change if this was moved to another OS? Would the major/only change be changing /usr/sbin/svcadm and /usr/bin/svcprop to point somewhere else? If so, it seems like those might be candidates to live in a member variable so that sub-classes could easily override those commands, but take advantage of the rest of the structure. __call would likely need to be overridden as well, but the other methods seem generic (but then I don't know much about how SMF has been ported to other OS's). image.py: 184-185: I can't figure out why this is needed here imageplan.py 700: I believe we want to do this even on keyboard interrupt, but would you confirm that. run.py: can't figure why this is in the change set t_actuators: 233-234: commented lines Brock _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
