SPEC: introduce "args" field and new error code
authorTom Denham <tom@tomdee.co.uk>
Mon, 13 Jun 2016 20:50:33 +0000 (13:50 -0700)
committerTom Denham <tom@tomdee.co.uk>
Tue, 14 Jun 2016 22:02:51 +0000 (15:02 -0700)
commit7b381a1af2c6120caf9a45a1b16eb86a25b165e5
tree3a59d8592d7e46c7729ccb0ab491b5a5ae2033c4
parentc3c08038177dfc3900b11ce54de55648d4b95184
SPEC: introduce "args" field and new error code

Based on previous discussions on the CNI maintainers calls, the spec is
unclear on 1) when CNI_ARGS should be used and 2) the fact the dynamic
config can be passed in through the network JSON.

This PR makes it clear that per-container config can be passed in
through the network JSON, adding a top level `args` field into
which orchestrators can add additional metadata without worrying that
plugins might reject the additional data. It also allows for plugins to
reject unknown fields passed in at the top level.

Using JSON is preferable to CNI_ARGS since it allows namespaced and
structured data. CNI_ARGS is a flat list of KV pairs which has reserved
characters with no escaping rules defined.
CNI_ARGS may still be used by orchestrators that want the simplicity of
passing the network config JSON as specified by the user, unchanged
through to the CNI plugin. But for any kind of structured data, it's
recommended that the `args` field in the JSON is used instead.
SPEC.md