Struct NetworkConfig 

pub struct NetworkConfig {
    pub cni_version: Version,
    pub name: String,
    pub plugin: String,
    pub args: HashMap<String, Value>,
    pub ip_masq: bool,
    pub ipam: Option<IpamConfig>,
    pub dns: Option<Dns>,
    pub runtime: Option<RuntimeConfig>,
    pub prev_result: Option<Value>,
    pub specific: HashMap<String, Value>,
}

Top-level network configuration.

This is the structure that is provided to plugins by CNI, not the structure that administrators write to configure CNI. As such, some fields defined in the spec to only exist in the administrative schema are not included here.

This struct’s members include all fields described by the spec, as well as a specific field which is a map of Strings to Values, and will catch any custom fields present at the top level of the configuration. There are other specific fields in some of the structs that are in fields below.

In general, this structure will only ever be read or modified by a plugin, but all fields are public to allow construction if necessary.

Fields

cni_version: Version

Version of the CNI spec to which this configuration conforms.

This is a Semantic Version 2.0 version number, and that is enforced here by being a Version, not a string.

This version must be used when creating replies, which include a similar field. The spec does not currently cover the case where an ErrorReply must be created before the config is parsed, or in cases of unparseable config; this is under discussion.

name: String

Name of the network configuration.

This is unique across all network configurations on a host (or other administrative domain). There are format restrictions but as this field will always be provided by the CNI runtime and is not to be created or altered by plugins, those are not checked here.

plugin: String

Name of the top-level plugin binary on disk.

This is called type in the JSON.

The “top-level” distinction is because a config may include an IPAM section, which contains its own plugin field, and this full configuration is provided to all sub plugins (via delegation), so a plugin may receive a configuration where this field doesn’t match its own name.

args: HashMap<String, Value>

Arbitrary arguments passed by the runtime.

This is a map of arbitrary arguments passed by the runtime, which might be on their own or on behalf of the user/operator. Plugins are free to ignore it if they’re not expecting anything within.

This replaces the older and deprecated CNI_ARGS environment variable, which this library doesn’t read (you may do so yourself if needed).

ip_masq: bool

Set up an IP masquerade on the host for this network.

This is an optional, “well-known” configuration field.

If true, and if the plugin supports it, an IP masquerade must be set up on the host for this network.

ipam: Option<IpamConfig>

IP Address Management sub-config.

This is an optional, “well-known” configuration field.

If present, and if the plugin supports it, the IPAM plugin specified by the plugin field of IpamConfig must be invoked via delegation.

dns: Option<Dns>

DNS sub-config.

This is an optional, “well-known” configuration field.

If present, and if the plugin supports it, the DNS settings specified must be configured for this network.

Note that this section is sourced from the administrative configuration. There is another field for runtime-provided DNS settings when supported, see RuntimeConfig.

runtime: Option<RuntimeConfig>

Dynamic information provided by the runtime.

This is an optional, “well-known” configuration field, named runtimeConfig in the spec, which is derived from the capabilities field only present in the administrative configuration.

Plugins can request that the runtime insert this dynamic configuration by explicitly listing their capabilities in the administrative configuration. Unlike the args field, plugins are expected to act on the data provided, and should not ignore it if they can’t.

prev_result: Option<Value>

The result of the previous plugin in a chain.

This is the prevResult field in the spec.

This field may contain anything, but most likely contains a SuccessReply or IpamSuccessReply. You should use serde_json::from_value to reinterpret it as whatever you expect it to be.

Plugins provided a prev_result as part of their input configuration must per spec output it as their result, with any possible modifications made by that plugin included. If a plugin makes no changes that would be reflected in the success reply, then it must output a reply equivalent to the provided prev_result.

In a CHECK operation, the plugin must consult the prev_result to determine the expected interfaces and addresses.

specific: HashMap<String, Value>

Custom top-level fields.

This is a serde(flatten) field which aggregates any and all additional custom fields not covered above.

Plugins may use this for custom configuration.

Trait Implementations

impl Clone for NetworkConfig

fn clone(&self) -> NetworkConfig

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for NetworkConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for NetworkConfig

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for NetworkConfig

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.