Getting rid of "master"s and "slave"s in favour of "parent" and "sub-"interfaces in the name of PC :)

Author: Levovar

Diff for: README.md

@@ -279,8 +279,8 @@ This way users can dynamically configure various networking solutions via the sa
 A generic framework supporting this method is built into DANM's code, but still this level of integration requires case-by-case implementation.
 As a result, DANM currently supports two integration levels:
 
- - **Dynamic integration level:** CNI-specific network attributes (such as IP ranges, master host devices etc.) can be controlled on a per network level, taken directly from a DanmNet object
- - **Static integration level:** CNI-specific network attributes (such as IP ranges, master host devices etc.) can be only configured on a per node level, via a static CNI configuration files (Note: this is the default CNI configuration method)
+ - **Dynamic integration level:** CNI-specific network attributes (such as IP ranges, parent host devices etc.) can be controlled on a per network level, taken directly from a DanmNet object
+ - **Static integration level:** CNI-specific network attributes (such as IP ranges, parent host devices etc.) can be only configured on a per node level, via a static CNI configuration files (Note: this is the default CNI configuration method)
 
 Our aim is to integrate all the popular CNIs into the DANM eco-system over time, but currently the following CNI's achieved dynamic integration level:
 
@@ -336,8 +336,8 @@ DANM's IPVLAN CNI uses the Linux kernel's IPVLAN module to provision high-speed,
 4.9, 4.11, or 4.14 would be even better (lotta bug fixes)*
 
 The CNI provisions IPVLAN interfaces in L2 mode, and supports the following extra features:
-* attaching IPVLAN slaves to any host interface
-* attaching IPVLAN slaves to dynamically created VLAN or VxLAN host interfaces
+* attaching IPVLAN sub-interfaces to any host interface
+* attaching IPVLAN sub-interfaces to dynamically created VLAN or VxLAN host interfaces
 * renaming the created interfaces according to the "container_prefix" attribute defined in the DanmNet object
 * allocating IP addresses by using DANM's flexible, in-built IPAM module
 * provisioning generic IP routes into a configured routing table inside the Pod's network namespace

Diff for: schema/DanmNet.yaml

@@ -18,9 +18,9 @@ spec:
   NetworkID: ## NETWORK_NAME  ##
   # This parameter, if present, denotes which backend willl be used to provision the container interfaces connected to this network.
   # Currently supported values with dynamic integration level are IPVLAN (default), SRIOV, or MACVLAN.
-  # - IPVLAN option results in an IPVLAN slave interface provisioned in L2 mode, and connected to the designated host device
+  # - IPVLAN option results in an IPVLAN sub-interface provisioned in L2 mode, and connected to the designated host device
   # - SRIOV option pushes an already existing Virtual Function of the configured host device to the container's netns
-  # - MACVLAN option results in a MACVLAN slave interface provisioned in bridge mode, and connected to the designated host device
+  # - MACVLAN option results in a MACVLAN sub-interface provisioned in bridge mode, and connected to the designated host device
   # For any other CNI backend DANM will read their configuration from the configured CNI config directory.
   # E.g. when a Pod is connected to a DanmNet with "NetworkType" set to "flannel", DANM will pass the content of /etc/cni/net.d/flannel.conf file to the /opt/cni/bin/flannel binary by invoking a standard CNI operation.
   # The default IPVLAN backend will be used if this parameter is not specified.
@@ -31,11 +31,11 @@ spec:
   # Dynamic configuration is supported only for IPVLAN, and SRIOV backends.
   # Other networks are always provisioned from static configuration. Options are silently ignored if NetworkType is set to a non-dynamically integrated backend.
   Options:
-    # Name of the master host device (i.e. physical host NIC).
-    # Slave interfaces are connected to this NIC in case NetworkType is set to IPVLAN, or MACVLAN.
+    # Name of the parent host device (i.e. physical host NIC).
+    # Sub-interfaces are connected to this NIC in case NetworkType is set to IPVLAN, or MACVLAN.
     # A Virtual Function belonging to this Physical Function is taken-up in case NetworkType is set to SRIOV.
     # OPTIONAL - STRING
-    host_device: ## MASTER_DEVICE_NAME ##
+    host_device: ## PARENT_DEVICE_NAME ##
     # The IPv4 CIDR notation of the subnet associated with the network.
     # Pods connecting to this network will get their IPs from this subnet, if defined.
     # Only has an effect with dynamically integrated backends. Ignored for other NetworkTypes.