On Fri, Dec 17, 2021 at 5:25 PM Felix Enrique Llorente Pastora <ellorent@redhat.com> wrote:On Fri, Dec 17, 2021 at 3:58 PM Dan Kenigsberg <danken@redhat.com> wrote:Thanks for sharing your plan.I would like to create a Linux bond of all the NICs of my machine, create a Linux bridge on top of it, and copy my original mac/IP/routing to that bridge. Can you share a policy that would let me express this desired state?You need to know the number of NICs, for example for three of them this would be it.Thanks. Having a Python-like `0:-1` slice index to select a sublist could be even cooler.More importantly, I would like to be able to select all interfaces which have vlan 204 enabled on their switch port, as reported by lldp. What would the capture look like in this case?
Is the suggested language expressive enough to capture them? Here's my (redacted) nmstate show for one such interface. I find the LLDP portion there a bit confusing.- ethernet:
auto-negotiation: true
duplex: full
speed: 10000
ipv4:
address: []
auto-dns: true
auto-gateway: true
auto-route-table-id: 0
auto-routes: true
dhcp: true
enabled: true
ipv6:
address: []
autoconf: false
dhcp: false
enabled: false
lldp:
enabled: true
neighbors:
- - system-name: sw01-access-f1.example.com
type: 5
- system-description: 'Juniper Networks, Inc'
type: 6
- system-capabilities:
- MAC Bridge component
- Router
type: 7
- _description: MAC address
chassis-id-type: 4
type: 1
- _description: Interface name
port-id: xe-0/0/17
port-id-type: 5
type: 2
- ieee-802-1-vlans:
- name: vlan-204
vid: 204
- name: vlan-205
vid: 205
subtype: 3
type: 127
- ieee-802-3-mac-phy-conf:
autoneg: false
operational-mau-type: 0
pmd-autoneg-cap: 32768
oui: 00:12:0f
subtype: 1
type: 127
- management-addresses:
address-subtype: ipv4
interface-number: 0
interface-number-subtype: 1
type: 8
- ieee-802-3-max-frame-size: 9216
oui: 00:12:0f
subtype: 4
type: 127
mtu: 1500
name: ens1f0
state: up
type: ethernetapiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bra1
spec:
capture:
default-gw: routes.running.destination=="0.0.0.0/0"
primary-iface: interfaces.name==capture.default-gw.routes.running.0.next-hop-interface
ethernet-ifaces: interface.type==ethernet
desiredState:
interfaces:
- name: bond1
type: bond
state: up
link-aggregation:
mode: balance-rr
options:
miimon: '140'
port:
- name: "{{ capture.ethernet-ifaces.interfaces.0.name }}"
- name: "{{ capture.ethernet-ifaces.interfaces.1.name }}"
- name: "{{ capture.ethernet-ifaces.interfaces.2.name }}"
- name: br1
description: Linux bridge with base interface as a port
type: linux-bridge
state: up
mac-address: "{{ capture.primary-iface.interfaces.0.mac-address }}"
ipv4: "{{ capture.primary-iface.interfaces.0.ipv4 }}"
bridge:
options:
stp:
enabled: false
port:
- bondallI suspect you need `bond1` here?
--Regards,Dan.On Thu, Dec 16, 2021 at 11:24 AM Alona Paz <alkaplan@redhat.com> wrote:Hi all,The kubevirt networking team is working on a new cmd/lib tool to generate dynamic NMState configurations.When networking configuration for a cluster is needed and all the details are common between the nodes in the cluster a NMState yaml configuration is enough.
Problems arise when some of the network configuration details are different between nodes and depend on the current node network state.
For that a different NMState yaml configuration needs to be generated per node and that's not convenient for big clusters and also at scale up scenarios.
The NMPolicy goal is to solve this problem.
Given a node network state and a network configuration policy (common to the cluster), the NMPolicy tool will generate a node specific desired network state.
NMPolicy was already integrated to kubernetes-nmstate and a usage example can be found here.
CLI Usage example -
Simulated --help output
Creating a new bridge with the base interface as its port. The bridge will get the mac address of the base interface.
Output of - nmstatectl show | nmpolicyctl gen policy.yaml
--~/.cache/nmpolicy/cache.yaml (the default captured states output file)
Stdout (the desired state to be applied by nmstatectl)
For more details, please review the design doc and share your feedback about it.Thanks,Alona.
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CAJOMPacxNke2pJnjJ1PKxz0f%3Dmm%3DrNpnWqZwAMtNXf7f0HXL_Q%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CAHOEP56e4zhHPtP8rZp%3D%3DZ_zf_XyTb-hOB%2BvVOiwMX%3DniqRNrg%40mail.gmail.com.
--Quique LlorenteCNV networking Senior Software Engineer