You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
runtime: Document state annotations as a copy of config annotations
The spec was not very clear on how state annotations are related to
config annotations. In the pull-request that landed state
annotations, it sounds like these were supposed to be copied opaquely
from the config [1]. It's still not clear to me why we'd copy
annotations but not the rest of the config [2], but I'm leaving that
alone for now.
There was previous interest in runtime-specified annotations [3,4]
(e.g. a RunV socket path [5]), but this commit does not allow runtimes
to inject additional entries because I don't like:
* Relying on config authors to avoid squatting on the namespace used
by the runtime (if ties are broken in favor of the config) or
* Silently clobbering configured annotations (if ties are broken in
favor of the runtime).
My preference would be to follow [3] and:
* Only include runtime-specified information in the state annotations.
* Require state readers to follow 'bundle' to the config.json if they
wanted configured annotations (or embed the whole config.json in the
state).
But with 1.0 released and spec-maintainer comments like [1], I think
it's too late to return to that approach. If we want to expose
runtime-specified annotations, I think we'll need a new state
property. There has been previous discussion of using "labels" and
"annotations" to carry both types of information in the state [6], and
while it's not as elegant as a full config copy, the
labels/annotations approach is still viable.
[1]: opencontainers#484 (comment)
[2]: opencontainers#484 (comment)
[3]: opencontainers#188
[4]: opencontainers#331 (comment)
[5]: opencontainers#188 (comment)
[6]: opencontainers#331 (comment)
Signed-off-by: W. Trevor King <[email protected]>
0 commit comments