-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Sync HookState struct with OCI spec #1201
Conversation
I noticed that the json name of This modification is a breakdown to backward compatibility but we have to do it, and the earlier the better. We should follow the name of the spec, this is important. |
Pid int `json:"pid"` | ||
Root string `json:"root"` | ||
BundlePath string `json:"bundlePath"` | ||
Annotations map[string]string `json:"annotations"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you've added fields, can you please update the code to actually fill them? And also add some tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I'm already doing this now, was sending this for a first glance in case someone is against this.
I was just thinking that the Status
field is not very useful, because prestart
,poststart
,poststop
happens at special time point and we don't need the status to identify container status, so I am also modifying the spec and trying to sync up HookState struct between spec and runc. :-)
I‘ve sent another PR to |
e1ddd3e
to
0b43200
Compare
`HookState` struct should follow definition of `State` in runtime-spec: * modify json name of `version` to `ociVersion`. * Remove redundant `Rootfs` field as rootfs can be retrived from `bundlePath/config.json`. Signed-off-by: Zhang Wei <[email protected]>
0b43200
to
a344b2d
Compare
This is ready for review, Janky is also good, ping @cyphar @hqhq @mrunalp @crosbymichael |
config.Labels = append(config.Labels, fmt.Sprintf("bundle=%s", expectedBundlePath)) | ||
|
||
getRootfsFromBundle := func(bundle string) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not declare this as a function in utils_test.go
. Seems a bit odd to define it like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because this is a temporary function which is only used by TestHook
, so I thought it's not worth a standalone function, and utils_test.go
should contain common functions. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh, okay. I don't really like it but it's just a test so w/e.
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess is unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone two. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]> Signed-off-by: Dongsu Park <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]> Signed-off-by: Dongsu Park <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]> Signed-off-by: Dongsu Park <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]> Signed-off-by: Dongsu Park <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. And add len guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 Signed-off-by: W. Trevor King <[email protected]> Signed-off-by: Dongsu Park <[email protected]> Signed-off-by: Aleksa Sarai <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. I really think we should have len() guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Aleksa, however, is adamantly against them [3] citing a risk of sloppy copy/pastes causing the hook slice being len-guarded to diverge from the hook slice being iterated over within the guard. I think that ort of thing is very lo-risk, because: * We shouldn't be copy/pasting this, right? DRY for the win :). * There's only ever a few lines between the guard and the guarded loop. That makes broken copy/pastes easy to catch in review. * We should have test coverage for these. Guarding with the wrong slice is certainly not the only thing you can break with a sloppy copy/paste. But I'm not a maintainer ;). [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 [3]: opencontainers#1741 Signed-off-by: W. Trevor King <[email protected]>
Finish off the work started in a344b2d (sync up `HookState` with OCI spec `State`, 2016-12-19, opencontainers#1201). And drop HookState, since there's no need for a local alias for specs.State. Also set c.initProcess in newInitProcess to support OCIState calls from within initProcess.start(). I think the cyclic references between linuxContainer and initProcess are unfortunate, but didn't want to address that here. I've also left the timing of the Prestart hooks alone, although the spec calls for them to happen before start (not as part of creation) [1,2]. Once the timing gets fixed we can drop the initProcessStartTime hacks which initProcess.start currently needs. I'm not sure why we trigger the prestart hooks in response to both procReady and procHooks. But we've had two prestart rounds in initProcess.start since 2f27649 (Move pre-start hooks after container mounts, 2016-02-17, opencontainers#568). I've left that alone too. I really think we should have len() guards to avoid computing the state when .Hooks is non-nil but the particular phase we're looking at is empty. Aleksa, however, is adamantly against them [3] citing a risk of sloppy copy/pastes causing the hook slice being len-guarded to diverge from the hook slice being iterated over within the guard. I think that ort of thing is very lo-risk, because: * We shouldn't be copy/pasting this, right? DRY for the win :). * There's only ever a few lines between the guard and the guarded loop. That makes broken copy/pastes easy to catch in review. * We should have test coverage for these. Guarding with the wrong slice is certainly not the only thing you can break with a sloppy copy/paste. But I'm not a maintainer ;). [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#prestart [2]: opencontainers#1710 [3]: opencontainers#1741 (comment) Signed-off-by: W. Trevor King <[email protected]>
* modify json name of
ociVersion
toversion
* Add missingStatus
andAnnotations
fieldSigned-off-by: Zhang Wei [email protected]
Edit:
HookState
struct should follow definition ofState
in runtime-spec:Rootfs
field as rootfs can be retrived frombundlePath/config.json