Replies: 1 comment
-
I don't think we currently have a way to do that, since containerd is not assuming that the OCI bundle is modified outside of containerd. If you are using CRI, NRI plugins can be used to mutate (a subset of) the OCI config prior to handoff to the shim & runtime (and those mutations should be reflected in containerd's store), though NRI is only supported for the CRI endpoint and only handles a subset of changes to the config. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey all,
I'm currently using a couple different modified runtimes that modify the underlying OCI spec. Separately, I have a host-level reconciler that uses the containerd API to periodically scan the state of all containers on the system and make them available in a runtime agnostic fashion. I want to add some metadata from the OCI spec post-mutation, but it appears that the containerd API returns the original spec serialized into its db and not the spec on disk.
Is there a straightforward way to get the on-disk bundle/get the location of the on-disk bundle? Reviewing the code I can figure out how to reconstruct the bundle path based off conventions (root + runtime + namespace + container id), but afaict I cannot get containerd to just tell me that location so I don't have to hardcode the convention.
Beta Was this translation helpful? Give feedback.
All reactions