Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

*: Remove hooks #483

Closed
wants to merge 1 commit into from
Closed

*: Remove hooks #483

wants to merge 1 commit into from

Conversation

wking
Copy link
Contributor

@wking wking commented Jun 2, 2016

This drops all instances (outside the ChangeLog) turned up by
case-insensitive searches for 'hook'.

The desire to drop hooks has been around for a while now, but it
took a while to land a create/start split. By the time that split did
land, dropping hooks was still part of its motivation. Hooks are
hard to support robustly, and after the create/start split,
callers can do whatever they like at those times without having to go
through the runtime
. There is still a use-case for folks who
prefer the old all-in-one UX, but we can support those folks with a
higher-level wrapper built on hookless create/start primatives.
There was some last-minute discussion of pre-pivot mount propagation
needing pre-start hooks
, but that use case can be addressed by
manipulating the mounts array. With those arguments in place, the
consensus at today's meeting seemed in favor of removing hooks from
the spec
.

Fixes #473.
Fixes #472.
Fixes #427.
Fixes #395.
Fixes #20.

@mrunalp
Copy link
Contributor

mrunalp commented Jun 2, 2016

I'm not sure about this and have started a thread on the mailing list.

@wking
Copy link
Contributor Author

wking commented Jun 2, 2016

On Thu, Jun 02, 2016 at 08:38:24AM -0700, Mrunal Patel wrote:

I'm not sure about this and have started a thread on the mailing
list.

Link to thread 1.

 Subject: Hooks and all-in-one operation
 Date: Wed, 1 Jun 2016 11:38:27 -0700
 Message-ID: <CANEZBD69Q4VV4UoBodWjtAR1PrJ1OysaMUHgA5cW_aGj2ZEhLQ@mail.gmail.com>

@jamesodhunt
Copy link

This isn't strictly relevant to the OCI spec, but hooks are currently used by docker to configure the container network. If they go away, it's unclear to me how networking will be handled, so this change could well break docker.

Maybe hooks should be retained until there is some sort of OCI network spec since, like annotations, they are a useful facility to handle arbitrary container scenarios.

@wking
Copy link
Contributor Author

wking commented Jun 17, 2016

On Fri, Jun 17, 2016 at 01:53:59AM -0700, James Hunt wrote:

If they go away, it's unclear to me how networking will be handled…

We should keep discussion in @mrunalp's thread 1 to avoid
fragmentation. I think 2 addresses your concerns, but if not, post
to the list thread with why ;).

 Subject: Re: Hooks and all-in-one operation
 Date: Thu, 9 Jun 2016 14:50:49 -0700
 Message-ID: <20160609215049.GK8801@odin.tremily.us>

This drops all instances (outside the ChangeLog) turned up by
case-insensitive searches for 'hook'.

The desire to drop hooks has been around for a while now [1], but it
took a while to land a create/start split.  By the time that split did
land, dropping hooks was still part of its motivation [2].  Hooks are
hard to support robustly [3], and after the create/start split,
callers can do whatever they like at those times without having to go
through the runtime [4].  There is still a use-case for folks who
prefer the old all-in-one UX, but we can support those folks with a
higher-level wrapper built on hookless create/start primatives [5].
There was some last-minute discussion of pre-pivot mount propagation
needing pre-start hooks [6], but that use case can be addressed by
manipulating the mounts array [7].  With those arguments in place, the
consensus at today's meeting seemed in favor of removing hooks from
the spec [8].  And after some second-guessing [9], we're now back in
favor of removing hooks from the spec [10].

[1]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2015/opencontainers.2015-10-28-17.02.log.html#l-71
     <wking> if you have a distinct create operation, you can drop the
       pre-start hooks, which makes a simpler spec
[2]: opencontainers#384
     Subject: Split create and start

     In the topic post:

     > # Motivating usecases:
     >
     > * to simplify the flows/interaction patterns by removing hooks,
     >   but still allow for the same functionality

[3]: opencontainers#265
     Subject: runtime-config: Require serial hook execution
[4]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2016-03-24.log.html#t2016-03-24T18:56:15
     <vishh> mrunalp: How do I run http hooks? I need a binary wrapper
       to execute http hooks
[5]: https://groups.google.com/a/opencontainers.org/d/msg/dev/Y7p6YW8zr4s/OVaAI_WDBAAJ
     Subject: Re: Hooks and all-in-one operation
     Date: Wed, 1 Jun 2016 11:49:07 -0700
     Message-ID: <20160601184907.GF4149@odin.tremily.us>
[6]: opencontainers#384 (comment)
     Subject: Split create and start
[7]: opencontainers#384 (comment)
     Subject: Split create and start
[8]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-06-01-17.01.log.html#l-83
[9]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/Y7p6YW8zr4s
     Subject: Hooks and all-in-one operation
     Date: Wed, 1 Jun 2016 11:38:27 -0700
     Message-ID: <CANEZBD69Q4VV4UoBodWjtAR1PrJ1OysaMUHgA5cW_aGj2ZEhLQ@mail.gmail.com>
[10]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-08-03-21.01.log.html#l-21

Signed-off-by: W. Trevor King <wking@tremily.us>
@wking
Copy link
Contributor Author

wking commented Aug 13, 2016

On Fri, Jun 17, 2016 at 09:09:31AM -0700, W. Trevor King wrote:

We should keep discussion in @mrunalp's thread [1] to avoid
fragmentation.

[1]: #483 (comment)

I posted to the thread on Tuesday asking for guidance now that the
consensus seems to have swung back around to “drop hooks”, but haven't
heard back. Rebasing this into master turned out to be not
particularly bad, so I just went ahead and did it with ea41a14
0113d7a.

@wking
Copy link
Contributor Author

wking commented Aug 17, 2016

So consensus on today's meeting was to keep hooks 1. To square
that against the DockerCon decision to drop them 2, the current
consensus on facts seem to be:

a. The create/start split lets you do any hook-like things you like
without hooks.
b. There are significant existing users who are using hooks as they
stand.
c. Specifying hooks will take some effort to get right.
d. The OCI will likely manage the hook spec if that gets punted to a
higher layer.
e. Nobody wants folks relying on unspecified behavior for important
stuff like network setup.
f. Once you put something into 1.0, you need to wait until 2.0 to take
it back out.

Possible approaches:

i. Include both hooks and the create/start split in this spec.
ii. Require the create/start split in this spec, and define hooks but
make them a separate protocol 3.
iii. Punt the hook specification to a higher layer (possibly still
within the OCI, see (d)), and have a tool that reads a config
containing hook information, wraps the base runtime, and calls
the hook commands at the appropriate times.

The DockerCon decision seemed to revolve around (a) and (f), arguing
for removing hooks as a conservative step, and possibly adding them
back after 1.0 if there was a demonstrated need (although in the light
of (a), I'm not sure what that would have looked like).

Today's decision seemed to revolve around (b), (d), and (e). Because
of (d), punting doesn't really effect OCI time, so (c) is less
important for the OCI. It does slightly raise the cost for base
runtime implementers (who now have to handle hooks), but they aren't
that complicated to implement (they're more complicated to
specify/test ;).

The distinction between these three choices is small because of (d),
and the only real issue with carving hooks out into a separate
protocol/spec or not is (f). The consensus on today's call was that
the backwards-compatibility inertia from (b) was sufficient that (f)
was unlikely to be an issue.

@wking wking closed this Aug 17, 2016
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Aug 17, 2016
…k-lifecycle

Restore hook language removed by create/start split with some tweaks
to adjust to the new environment, for example:

* Put the pre-start hooks after the 'start' call, but before the meat
  of the start call (the container-process exec trigger).  Folks who
  want a post-create hook can add one with that name.  I'd like to
  have renamed poststop to post-delete to avoid confusion like [1].
  But the motivation for keeping hooks was backwards compatibility [2]
  so I've left the name alone.

* Put each "...command is invoked..." lifecycle entry in its own list
  entry, to match the 'create' list entry.

* Move the rules about what happens on hook failure into the
  lifecycle.  This matches pre-split entries like:

    If any prestart hook fails, then the container MUST be stopped and
    the lifecycle continues at step 7.

  and avoids respecifying that information in a second location
  (config.md).

* I added the warning section to try and follow post-split's generic
  "generates an error" approach while respecting the pre-split desire
  to see what failed (we had "then an error including the exit code
  and the stderr is returned to the caller" and "then an error is
  logged").

[1]: opencontainers#395
     Subject: Run post-stop hooks before the container sandbox is deleted.
[2]: opencontainers#483 (comment)
     Subject: *: Remove hooks

* duglin/SplitCreate:
  Split create and start

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Feb 3, 2017
I expect the lifecycle information was removed accidentally in
be59415 (Split create and start, 2016-04-01, opencontainers#384), because for a
time it seemed like that PR would also be removing hooks.  Putting the
lifecycle information back in, I made some tweaks to adjust to the new
environment, for example:

* Put the pre-start hooks after the 'start' call, but before the meat
  of the start call (the container-process exec trigger).  Folks who
  want a post-create hook can add one with that name.  I'd like to
  have renamed poststop to post-delete to avoid confusion like [1].
  But the motivation for keeping hooks was backwards compatibility [2]
  so I've left the name alone.

* Put each "...command is invoked..." lifecycle entry in its own list
  entry, to match the 'create' list entry.

* Move the rules about what happens on hook failure into the
  lifecycle.  This matches pre-split entries like:

    If any prestart hook fails, then the container MUST be stopped and
    the lifecycle continues at step 7.

  and avoids respecifying that information in a second location
  (config.md).

* I added the warning section to try and follow post-split's generic
  "generates an error" approach while respecting the pre-split desire
  to see what failed (we had "then an error including the exit code
  and the stderr is returned to the caller" and "then an error is
  logged").

* I left the state 'id' context out, since Michael didn't want it [3].

[1]: opencontainers#395
     Subject: Run post-stop hooks before the container sandbox is deleted.
[2]: opencontainers#483 (comment)
     Subject: *: Remove hooks
[3]: opencontainers#532 (comment)
     Subject: Restore hook language removed by create/start split

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Mar 1, 2017
I expect the lifecycle information was removed accidentally in
be59415 (Split create and start, 2016-04-01, opencontainers#384), because for a
time it seemed like that PR would also be removing hooks.  Putting the
lifecycle information back in, I made some tweaks to adjust to the new
environment, for example:

* Put the pre-start hooks after the 'start' call, but before the meat
  of the start call (the container-process exec trigger).  Folks who
  want a post-create hook can add one with that name.  I'd like to
  have renamed poststop to post-delete to avoid confusion like [1].
  But the motivation for keeping hooks was backwards compatibility [2]
  so I've left the name alone.

* Put each "...command is invoked..." lifecycle entry in its own list
  entry, to match the 'create' list entry.

* Move the rules about what happens on hook failure into the
  lifecycle.  This matches pre-split entries like:

    If any prestart hook fails, then the container MUST be stopped and
    the lifecycle continues at step 7.

  and avoids respecifying that information in a second location
  (config.md).

* I added the warning section to try and follow post-split's generic
  "generates an error" approach while respecting the pre-split desire
  to see what failed (we had "then an error including the exit code
  and the stderr is returned to the caller" and "then an error is
  logged").

* I left the state 'id' context out, since Michael didn't want it [3].

[1]: opencontainers#395
     Subject: Run post-stop hooks before the container sandbox is deleted.
[2]: opencontainers#483 (comment)
     Subject: *: Remove hooks
[3]: opencontainers#532 (comment)
     Subject: Restore hook language removed by create/start split

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Mar 3, 2017
I expect the lifecycle information was removed accidentally in
be59415 (Split create and start, 2016-04-01, opencontainers#384), because for a
time it seemed like that PR would also be removing hooks.  Putting the
lifecycle information back in, I made some tweaks to adjust to the new
environment, for example:

* Put the pre-start hooks after the 'start' call, but before the meat
  of the start call (the container-process exec trigger).  Folks who
  want a post-create hook can add one with that name.  I'd like to
  have renamed poststop to post-delete to avoid confusion like [1].
  But the motivation for keeping hooks was backwards compatibility [2]
  so I've left the name alone.

* Put each "...command is invoked..." lifecycle entry in its own list
  entry, to match the 'create' list entry.

* Move the rules about what happens on hook failure into the
  lifecycle.  This matches pre-split entries like:

    If any prestart hook fails, then the container MUST be stopped and
    the lifecycle continues at step 7.

  and avoids respecifying that information in a second location
  (config.md).

* I added the warning section to try and follow post-split's generic
  "generates an error" approach while respecting the pre-split desire
  to see what failed (we had "then an error including the exit code
  and the stderr is returned to the caller" and "then an error is
  logged").

* I left the state 'id' context out, since Michael didn't want it [3].

* Make runtime.md references to "generate an error" and "log a
  warning" links, so readers have an easier time finding more detail
  on that wording.

Where I reference a section, I'm still using the auto-generated anchor
for that header and not the anchors which were added in 41839d7 (Merge
pull request opencontainers#707 from mrunalp/anchor_tags, 2017-03-03) and similar.
Mrunal suggested that the manually-added anchors were mainly intended
for the validation tooling [4].

[1]: opencontainers#395
     Subject: Run post-stop hooks before the container sandbox is deleted.
[2]: opencontainers#483 (comment)
     Subject: *: Remove hooks
[3]: opencontainers#532 (comment)
     Subject: Restore hook language removed by create/start split
[4]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2017-03-03.log.html#t2017-03-03T18:02:12

Signed-off-by: W. Trevor King <wking@tremily.us>
@wking wking mentioned this pull request Apr 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants