Support of additional configuration for the forwarders (device-selector)

[LionelJouin]

Describe the problem you're solving.

Some forwarders require additional configuration in order to work properly. For instance, the vlan mechanism with the vpp forwarder needs a configmap to know on which host interface the vlan interface will be based on.

device-selector configmap:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: device-selector
data:
  selector: "---\ninterfaces:\n
    \  - name: eth0\n
    \    matches:\n
    \       - labelSelector:\n
    \          - via: eth0\n
    \  - name: eth1\n
    \    matches:\n
    \       - labelSelector:\n
    \          - via: eth1\n
    \  - name: eth2\n
    \    matches:\n
    \       - labelSelector:\n
    \          - via: eth2\n
    \  - name: eth3\n
    \    matches:\n
    \       - labelSelector:\n
    \          - via: eth3\n     \n"

forwarder-vpp:

kind: DaemonSet
metadata:
  name: forwarder-vpp
spec:
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      containers:
        - name: forwarder-vpp
          env:
            - name: NSM_DEVICE_SELECTOR_FILE
              value: /var/lib/networkservicemesh/device-selector.yaml
          volumeMounts:
            - name: devsel-vol
              mountPath: /var/lib/networkservicemesh/device-selector.yaml
              subPath: device-selector.yaml
      volumes:
        - name: devsel-vol
          configMap:
            name: device-selector
            items:
            - key: selector
              path: device-selector.yaml

Describe that task step by step.

/

Describe alternatives you've considered or would consider

The issue could be addressed by multiple solution.

If all forwarders are using device selector with the same format with similar information, then if could be included as part of the Forwarder struct or it could be a new CRD.

If all forwarders are using different types of information, then the user could deploy the configmap before deploying the NSM CR, and refer the configmap inside a NSM CR.

Another solution could be to have an opened property in the forwarder struct where the user could write the configuration. For instance Multus is doing it: https://github.com/k8snetworkplumbingwg/multus-cni/blob/master/examples/README.md#passing-down-device-information

Additional context

/

[edwarnicke]

One suggestion I would make as we do this: use programming by default principles.

Which is to say: make it always possible to deploy with little to no config, with reasonable defaults. Don't make users specify all the nerd nobs. Think in terms of the Option pattern (analogized to this space).

Note: None of this is meant to proscribe anything specific here... its entirely about "Make sure to think about this too" :)