Skip to content
This repository was archived by the owner on Mar 23, 2020. It is now read-only.

Create Linux bridge on top of the default interface during the deployment #18

Closed
phoracek opened this issue Aug 9, 2019 · 6 comments
Closed

Comments

@phoracek
Copy link
Contributor

phoracek commented Aug 9, 2019

In order enable CNV to connect VMs to the enterprise network, we need to configure Linux bridge on top of the default interface. That should be done during the deployment.

Once CNV is deployed (via HCO, which should also bridge kubernetes-nmstate) we should run script that.

  1. Figures out what is the default interface name from NodeNetworkState (alternatively hardcode the name)
  2. Create NodeNetworkConfigurationPolicy which would configure Linux bridge on top of the interface. The bridge should have vlan_filtering enabled and obtain IP address via DHCP

Note that kubernetes-nmstate is not yet part of HCO, we hope to get it there during the next week. I will test the scenario and scripts we need in the meanwhile.

Resolved by #47

@russellb
Copy link
Member

russellb commented Aug 9, 2019

That should be done during the deployment.

This may be a bit pedantic, but this needs to be a post-install setup task as part of setting up CNV. It can be part of install-scripts though, so it's part of the overall KNI install procedure.

Ideally, HCO (or something under it) would handle this automatically without requiring extra steps in this repo.

@phoracek
Copy link
Contributor Author

phoracek commented Aug 9, 2019

I'd like to put it at the end of CNV's install-scripts. Executed after HCO is installed and Available.

It may end up in HCO, but there is no good practice yet for setting up bridges and I'm not sure whether there ever be one for arbitrary clusters.

If we know the name of default interface, it should be as simple as applying a manifest. If we don't, we may need to add some (simple) script.

@rthallisey
Copy link
Contributor

cc @karmab

@phoracek
Copy link
Contributor Author

I have tested it today on bare metal machines prepared for KNI. I deployed kubernetes-nmstate using network addons operator, it successfully reported interfaces and configured some. Unfortunately later I ran into some troubles during the setup while moving IP and routing. Investigating it now with nmstate developers.

Just for the record, this is the script I used (installation would be done via HCO):

# install network addons operator
oc apply -f https://raw.githubusercontent.com/kubevirt/cluster-network-addons-operator/master/manifests/cluster-network-addons/0.12.0/namespace.yaml
oc apply -f https://raw.githubusercontent.com/kubevirt/cluster-network-addons-operator/master/manifests/cluster-network-addons/0.12.0/network-addons-config.crd.yaml
oc apply -f https://raw.githubusercontent.com/kubevirt/cluster-network-addons-operator/master/manifests/cluster-network-addons/0.12.0/operator.yaml

# install nmstate
cat <<EOF | oc create -f -
apiVersion: networkaddonsoperator.network.kubevirt.io/v1alpha1
kind: NetworkAddonsConfig
metadata:
  name: cluster
spec:
  nmstate: {}
EOF

# get default interface, it is not currently used in the rest of the script
default_iface=$(oc get nodenetworkstate -o jsonpath='{.items[0].status.currentState.routes.running[?(@.destination=="0.0.0.0/0")].next-hop-interface}')

# create policy setting up the bridge
cat <<EOF | oc apply -f -
apiVersion: nmstate.io/v1alpha1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: brext-default-net
spec:
#  nodeSelector:
#    kubernetes.io/hostname: hostname
  desiredState:
    interfaces:
    - name: brext
      description: Linux bridge on top of the default network interface
      type: linux-bridge
      state: up
      ipv4:
        auto-dns: true
        auto-gateway: true
        auto-routes: true
        dhcp: true
        enabled: true
      ipv6:
        auto-dns: true
        auto-gateway: true
        auto-routes: true
        autoconf: true
        dhcp: true
        enabled: true
      bridge:
        options:
          stp:
            enabled: false
        port:
        - name: eno2
EOF

@e-minguez
Copy link
Contributor

e-minguez commented Sep 25, 2019

Can we close this @phoracek ?

@phoracek
Copy link
Contributor Author

Resolved via #47.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants