What does an impl do with Annotations?

[duglin]

The spec defines annotations in the config.json but it doesn't anything else about them.
For example, is that info suppose to be available via a runc state id type of operation?
If that info isn't retrievable/queriable then what is it for?

[wking]

On Wed, Jun 01, 2016 at 10:40:35AM -0700, Doug Davis wrote:

The spec defines annotations in the config.json but it doesn't
anything else about them.

They are explicitly opaque (“arbitrary” 1); the runtime doesn't care
what you do with them.

For example, is that info suppose to be available via a runc state id type of operation?

You can get to the original config.json using the state's bundlePath
[2,3].

[duglin]

Is that the workflow people are expecting?

Meaning: use "runc xxx" to manipulate and get the state of the container but then access the filesystem directly to retrieve the annotations/config.json?

Would including config.json as part of the output of state() be so bad?

[wking]

On Wed, Jun 01, 2016 at 11:00:41AM -0700, Doug Davis wrote:

Is that the workflow people are expecting?

Meaning: use "runc xxx" to manipulate and get the state of the
container but then access the filesystem directly to retrieve the
annotations/config.json?

For more background on this approach (but in the context of mounting),
see assorted rebuttals to my pushback in this thread 1.

Would including config.json as part of the output of state() be so
bad?

My problem with including it is that the config.json entries may be
stale by the time you find them in the state. Folks should just ask
the kernel 2. But the kernel will not know about annotations and
such. I don't have a problem passing config.json's annotations
through to the state JSON 3. But what's your use-case? It may be
better to manage your own state-like registry with this sort of
metadata.

 Subject: Drop 'root' from state.json?
 Date: Thu, 3 Sep 2015 12:50:59 -0700
 Message-ID: <20150903195059.GF25638@odin.tremily.us>

[crosbymichael]

Nothing. The runtimes should do nothing with annotations, that is the point of having them.

[duglin]

See opencontainers/runc#869 for one possible way to deal with it.

[crosbymichael]

By nothing i meant no actions on the values, it can just pass them through and return them in the state.

[duglin]

yea, I assumed you were focused on the "no action" side of things. If people are happy with your runc PR, I think having a similar change in the spec would be good so that people have a consistent way to get this info from OCI complaint runtimes.

[crosbymichael]

Ya, it would make sense to have this in the spec as a part of the state return result

[wking]

On Thu, Jun 02, 2016 at 12:55:05PM -0700, Doug Davis wrote:

If people are happy with your runc PR, I think having a similar
change in the spec would be good so that people have a consistent
way to get this info from OCI complaint runtimes.

I explicitly suggested this (for ‘labels’) 1 and it was rejected
2. If we want to revisit “you can look that up using bundlePath” as
a valid reason to reject this sort of thing, I expect we'll end up
copying the whole config over.