spec: clarification for event handlers

[mpasternacki]

1. If multiple event handlers of the same name are defined, should they be executed in parallel, or one after another?
2. Are event handlers executed as root, or as parent application's user/group? A good use case for handlers would be privileged initialization (e.g. creating and chown-ing workspace for process, which requires root) to let the main process run as a non-privileged user.
3. Do event handlers run with parent app's environment, or with a clean one?

It may be useful to have event handlers more parameterized: it should be possible to specify at least user, group, and environment for the handler. If you are not opposed to that idea, I will prepare a pull request.

[philips]

On Fri, Dec 19, 2014 at 6:20 AM, Maciej Pasternacki
notifications@github.com wrote:

If multiple event handlers of the same name are defined, should they be executed in parallel, or one after another?

There should be only one, we should clarify that.

Are event handlers executed as root, or as parent application's user/group? A good use case for handlers would be privileged initialization (e.g. creating and chown-ing workspace for process, which requires root) to let the main process run as a non-privileged user.

Hrm, that is a good question. I am fine adding a gid/uid on that.

Do event handlers run with parent app's environment, or with a clean one?

Parallel with the current app's environment.

It may be useful to have event handlers more parameterized: it should be possible to specify at least user, group, and environment for the handler. If you are not opposed to that idea, I will prepare a pull request.

Sounds good!

Brandon

[jonboulle]

On Fri, Dec 19, 2014 at 6:20 AM, Maciej Pasternacki notifications@github.com wrote:

If multiple event handlers of the same name are defined, should they be executed in parallel, or one after another?

There should be only one, we should clarify that.

#62

[wereHamster]

If the event handlers need to be unique, why not use a JSON object instead of an array. Like you do with annotations?

[mpasternacki]

+1 on the JSON object suggestion, was about to ask that myself (asked in #62, which seems to be a better place for that).

[jonboulle]

For a little background: that was actually the case in earlier versions of the spec. The motivation for changing was that we had inconsistency between different fields - some were maps with user defined keys (as you're suggesting), and others were lists of key/value pairs (c.f. mountPoints, isolators, labels, etc). The nice thing about the latter is that it is then clear that everything on the left (i.e. the "key") is part of the schema and everything on the right is defined by users. It does mean it is a little more effort to parse/validate (e.g. since we need to guarantee uniqueness ourselves instead of delegating to JSON) but that is what we have computers for after all.

Annotations are the glaring exception remaining to this..

[jonboulle]

Capturing the other question raised in #62:

Why explicitly limit event names? Can't an implementation define additional events/handlers? Examples of such handlers would be: ad-hoc maintenance tasks triggered manually (like running chef-server-ctl commands for Chef server); cron-like scheduled tasks; handling situations in multi-application containers when one of the processes exits. Spec may require that if an implementation handles events outside of the spec, the event names should be namespaced (e.g. rocket:cron or jetpack:task) to avoid possible collisions.

We certainly want a small set of very well defined eventHandlers that all executor implementations must support. As for extensions like ad-hoc tasks, is that worth codifying in image manifests at all, rather than just leaving it up to implementations? I think it's a bit of a grey area. Namespacing could be a good compromise and we could define this as a common approach for dealing with other fields like isolators (optional; small set of well-known fields; other fields accepted, but please namespace; commonly-used fields may be promoted to well-known in future versions of the spec)