On Tue, Jun 21, 2011 at 8:37 AM, James Hunt <[email protected]> wrote: > Hi Evan, > > On 17/06/11 21:41, Evan Huus wrote: >> Very nice proposal! > Thanks! > >> >> I'm firmly committed to the idea that init and initctl should not be >> modifying anything in /etc/init >> - if such a tool would be convenient or necessary, then a separate utility >> should be created. Safer >> for everybody that way. > That's my view too. > >> = Terminology = >> >> * "limit" >> >> Since we want to be able to disable Upstart jobs based on some >> condition, "disable" is rather a crude term. The word "limit" is >> better since it connotes the more fine-grained approach being >> proposed. Its antonym being "delimit" (I'd initially thought of >> "restrict" and "derestrict" but (,de)limit is shorter :-) >> >> >> I disagree. To me, limit means not fully disabled, as in still partially >> functional. I would suggest >> stanza 'disable' (like manual, except cannot even be started manually). > I had started out with disable/enable in mind too (if nothing else for parity > with SysV > terminology). However, I think the resultant behaviour is more subtle with > Upstart so maybe it > deserves a different name? > > We are considering a facility that can disable a job entirely, but which can > also > restrict/limit/modify/a-n-other-term-here a jobs behaviour based on one or > more events being > emitted. And it can disable implicitly jobs which specify the original job in > their start on. > > However, I'd be happy with any of the names as long as the documentation is > clear on the precise > behaviour.
You're right that 'disable' doesn't fit well with the subtlety of the currently proposed implementation. I'm still not happy with 'limit' though, for reasons stated previously. How about 'block' instead? --- 15 minutes of reflection later --- My first though was that 'block' is just a better word for the same sort of stanza as you were proposing for 'limit', however I feel it could actually do with a slightly different syntax / implementation. Hopefully this would still accomplish the same high-level goal. The block stanza does what you might expect: it allows you to block signals/events. A job containing "block runlevel" in it's override file would simply never receive the runlevel event - upstart would try to deliver it and then realize that it's blocked for that job. Syntax for multiple blocks would be simpler than for 'start on' or 'stop on' because there is no need for and/or logic differentiation: block simply takes a flat list of signals (and optional parameters such as runlevel [34]), all of which are blocked from being delivered to the job. Example: conf file contains: start on runlevel [345] override file contains: block runlevel [34] result: runlevel [5] is still delivered, allowing the job to start only on that runlevel event To me, this seems much easier to conceptualize then any of the previous stanza proposals, and we don't end up with all the confusing corner cases that you listed in your original RFC. I'm not 100% sure that it's capable of covering all of the use cases that 'limit' was originally designed for, but it does cover most of them. Also of note, with this implementation " manual " could be deprecated in favour of " block * " or " block all ". --- Another 15 minutes of reflection later --- One of the cases this doesn't cover is a 'full disable' such that a job cannot be started, even manually. 'Block' is clearly not the right stanza for this, but 'disable' (with no parameters) is. I know it means adding two stanzas instead of one, but they really are covering considerably different cases, and the 'disable' stanza in this case is exceptionally simple. Also as an unintended bonus, I believe this neatly solves the problem of being able to block/disable/limit specific instances of a job (originally planned for revision 2). For example, take network-interface.conf on my Ubuntu Oneiric system. Adding "block net-device-added INTERFACE=eth0" to network-interface.override would theoretically disable only the eth0 instance of that job. Thoughts, concerns? Cheers, Evan -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
