-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
api/services/task: add RuntimeInfo() #8509
Conversation
9fcd53f
to
c9a386d
Compare
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.
LGTM
noting that for k8s they would likely need to use the CRI api ContainerStatus() .. see crictl info
for current example of verbose output. Both apis should return the same information.
In the CRI API, the runtime features are intended to be added to the |
As a feature that runtime will call, the documentation can be updated to suggest that shim developers implement this flag |
Added |
nod though it's called |
@dmcgowan PTAL |
4eba2c4
to
8aa955f
Compare
Rebased |
/retest |
Could we consider adding this function to a new service definition rather than to task v1. We have rejected changes like this in the past because v1 task definition is stable and no plans for a task v2. I think we already need something like a runtime introspection API. |
I’m not sure. I don’t feel the runtime info is decouplable from the task service. |
8aa955f
to
cf291ec
Compare
Annotations map[string]string | ||
} | ||
|
||
func (c *Client) RuntimeInfo(ctx context.Context, runtimePath string, runtimeOptions interface{}) (*RuntimeInfo, 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.
I'm not sure at which layer, but it would be nice to cache this info instead of running it every time.
If we require a containerd restart when you upgrade runc, it seems like a reasonable trade off IMHO.
What do you think?
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.
I'd say caching is the caller's responsibility
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.
Sure, not here in the client. But I mean, probably the runc manager can cache it, right? Or at some other layer we are modifying here?
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.
Runc binary can be updated without restarting the daemon, so I don’t think the daemon should cache the info.
@dmcgowan What should we do with this? |
Use `ctr task runtime-info` to test this. Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
cf291ec
to
08f8bcb
Compare
Rebased |
TODO: consider moving this to https://github.com/containerd/containerd/blob/main/api/services/introspection/v1/introspection.proto |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
New PR: Moved the method from the task service to the introspection service. |
The
RuntimeInfo()
method returns the OCI Runtime features that are implemented by the runtime.Expected to be used for:
RPC
Request:
Response:
Examples
Use
ctr task runtime-info
to test this.Default (runc)
crun (prior to v1.8.6)
The
Features
property is null becausecrun features
was not implemented until crun v1.8.6io.containerd.runsc.v1
Fails because
containerd-shim-runsc-v1 -info
is not implemented yet