Add CreateRuntime, CreateContainer and StartContainer Hooks

[RenaudWasTaken]

Hello!

This PR implements the new CreateRuntime hook as defined in https://github.com/opencontainers/runtime-spec/blob/master/config.md#posix-platform-hooks

This is a fairly simple change, CreateRuntime are basically prestart hooks with the requirement of being called after the now deprecated prestart hooks.

I've done of refactoring to not have too much duplication of code by adding a function: (*Hooks) RunHooks(name HookName, spec *specs.State) error.
This allows us to have a nicer statement in the code:

if err := c.config.Hooks.RunHooks(configs.Prestart, s); err != nil {
    return err
}

// Rather than
for i, hook := range c.config.Hooks.Prestart {
    if err := hook.Run(s); err != nil {
        return newSystemErrorWithCausef(err, "running prestart hook %d", i)
    }
}

I'm looking into how to implement the createContainer and startContainer changes but am not super familiar with the code base and would happily take pointers.

fixes #1710
cc @cyphar @mrunalp @vbatts

[h-vetinari]

Cool, thanks for tackling this!

But - may I ask - why not add all the hooks from opencontainers/runtime-spec#1008 in one PR?

[RenaudWasTaken]

@h-vetinari I'll be opening other PRs for these because they are less trivial 😛

[katiewasnothere]

@RenaudWasTaken is there a blocker here?

[RenaudWasTaken]

I just rebased my PR! Just getting a review for this specific piece of the hooks :)

[mikebrow]

couple comments...

[RenaudWasTaken]

Updated, thanks for the review @mikebrow !

[mikebrow]

LGTM non maintainer vote

[h-vetinari]

runtime-spec 1.0.2 was just released 🎉
So that means finishing this PR, plus implementing the other hooks, and then the potentially truly final release candidate 1.0.0-rc11 would be ready. 😊
(just a pity that rc7 was already nicknamed "the eleventh hour" 😋)

[h-vetinari]

@RenaudWasTaken Can you rebase this?

@crosbymichael @mrunalp @dqminh @hqhq @cyphar @AkihiroSuda
People are asking about releasing rc11 already, and I'm guessing this PR should be included (at least the impending resolution of the hook issue was announced with rc10)?

OTOH, if not all the hooks from opencontainers/runtime-spec#1008 are implemented for rc11, there'll have to be another rc anyway?

[cyphar]

(just a pity that rc7 was already nicknamed "the eleventh hour" yum)

Apologies -- it did look like it was going to be the final RC at the time. And what an innocent time that was. 😉 I'll change the nicknames once we do an rc11.

People are asking about releasing rc11 already, and I'm guessing this PR should be included (at least the impending resolution of the hook issue was announced with rc10)?

I don't mind doing an rc11 now since it seems Kubernetes is asking for one. But whether or not we merge this (I haven't reviewed it yet) is a separate concern to rc11 -- if we need rc11 we can merge it without this because we'd need to implement the other hooks for the final rc before 1.0 anyway.

OTOH, if not all the hooks from opencontainers/runtime-spec#1008 are implemented for rc11, there'll have to be another rc anyway?

Yes, there will have to be one RC which acts as the "feature freeze". Normally, RCs are all mean to be feature freezes but let's just say we've broken more than a couple of rules when it comes to how project releases should work. But as I've discussed here and on the OCI calls and mailing lists, we will change how runc does releases as soon as we've got 1.0.0 out of the door.

[AkihiroSuda]

Maybe dumb question, but can we consider shipping the next release as v11.0.0 to reflect the reality?

[h-vetinari]

@AkihiroSuda: Maybe dumb question, but can we consider shipping the next release as v11.0.0 to reflect the reality?

Maybe jumping to v2.0.0-rc1 for the feature-freeze would be enough to indicate that this has progressed far beyond what v1.0.0 was originally planned to be (resp. what API earlier release candidates "promised")?

OTOH, 1.0.0 presumably has sentimental value to some people involved here, so what's one more broken rule to finally get there? ;-)

[AkihiroSuda]

@RenaudWasTaken @cyphar What's current status?

[RenaudWasTaken]

Hello!

Sorry for the lag, the past few weeks have been complicated :)
I've rebased this branch and will likely spend some time this week to implement another (or all) hook(s) in a separate PR.

[RenaudWasTaken]

Small update, I've managed to take some to explore a bit more the code base and look into adding the other hooks.

While doing so, I noticed a few things that need to be added to this PR:

• Add the CreateRuntime to the Marshall / Unmarshall function
• Add the CreateRuntime to the speconv

Now that I'm a bit more familiar with the code base, it looks like the changes are less important than expected and might all go in this PR. More to come this weekend.

[RenaudWasTaken]

Added the other hooks, I'll spend an hour or two to add some go tests during the weekend.
I did manually manage to test all the hooks (and they work) :D !

[h-vetinari]

Awesome to see this being picked back up, thanks @RenaudWasTaken! Should also adapt the PR title accordingly.

[RenaudWasTaken]

Rebased :) !

@AkihiroSuda @cyphar Should we merge it and I'll create the followup two PRs:

• Transition tests to use the debian image
• Investigate removing the custom JSON serialization of the Hook structure

[RenaudWasTaken]

Sorry I didn't realize the CI wasn't passing, pushed an update :) !

[cyphar]

CentOS7 is failing because it doesn't use the Dockerfile and so skopeo isn't installed:

not ok 44 runc run (hooks library tests)
# (from function `get_and_extract_debian' in file tests/integration/multi-arch.bash, line 35,
#  from function `setup_debian' in file tests/integration/helpers.bash, line 449,
#  from function `setup' in test file tests/integration/hooks.bats, line 16)
#   `setup_debian' failed with status 127
# runc list (status=0):
# ID          PID         STATUS      BUNDLE      CREATED     OWNER
# /vagrant/tests/integration/multi-arch.bash: line 35: skopeo: command not found
# runc list (status=0):
# ID          PID         STATUS      BUNDLE      CREATED     OWNER

[RenaudWasTaken]

Hopefully fixed in this new one!

[cyphar]

Ah, you need to get umoci too. 😉 I'll do a final review of this today, but from a quick skim it should be good to merge and we can work on the other remaining topics (cleaning up the rest of the test suite to use one image and so on) later. Sorry about how long this took to get properly reviewed, and I'll buy you a beer if/when we meet up at a conference.

[RenaudWasTaken]

Updated!

[RenaudWasTaken]

Sorry about how long this took to get properly reviewed, and I'll buy you a beer if/when we meet up at a conference.

No worries, I'm used to open source now and I sometime take a long time to review PRs :D !
I will however happily accept the beer (and am happy to buy a few too!) if we ever cross at FOSDEM/Kubecon or any other conference!

[cyphar]

There are just a few minor nits left. I did notice you dropped the newSystemErrorWithCausef wrappers for hooks but that debug information has never been useful and we need to migrate to pkg/errors anyway so whatever.

[cyphar]

LGTM, thanks for slogging through this for so long.

[RenaudWasTaken]

I'll have the followup PRs by next week!