Now that we know Docker 1.11 will integrate with containerd (#20361), I'd like to understand how the OCI configuration (config.json) will be handled in docker 1.11.

Specifically,

• Who will "own" config.json?
• What will generate config.json?
• When will config.json be generated?

Assuming docker as the answer to the first 2 questions above, how will docker allow runtime-specific metadata be specified so that it ends up in "config.json"?

There are a few categories of runtime-specific (or even container-specific) metadata that might need to be passed to the OCI runtime:

• Hook configuration:

  • Prestart
  • Poststart
  • Poststop

• Annotations.

• VM-specific metadata

  For VM-based OCI runtimes (such as Clear Containers and runV, there is a need to specify extra meta-data such as:

  • rootfs path
  • kernel path
  • kernel options
  • initrd path
  • hypervisor options

  This is currently being discussed on the opencontainers mailing list. It's possible that the above could be handled entirely by Annotations but having a more structured approach that is formally part of the specification is desirable.

OCI Annotations sound remarkably like docker labels, however labels are not visible to the container.

In the OCI world, will that change (slightly) such that docker will add the labels into config.json as annotations which the runtime can choose to consume? That would seem like a convenient solution to the above requirements, however there may be security concerns (?) around passing all labels to the runtime via config.json.

I'm wondering therefore if docker would make a "privileged label namespace" such that any labels in that namespace are guaranteed to be exported to config.json (say "org.opencontainers.*"?) whilst all others would not.