Charm does not create VFs without a config-changed

Bug #1817079 reported by Nicolas Pochet
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Neutron Open vSwitch Charm
Fix Released
Undecided
Sahid Orentino

Bug Description

With the following extract from the bundle, the initial deployment of the charm does not create the virtual functions.

neutron-openvswitch:
    charm: cs:neutron-openvswitch
    num_units: 0
    bindings:
      data: *overlay-space
    options:
      worker-multiplier: *worker-multiplier
      bridge-mappings: *bridge-mappings
      prevent-arp-spoofing: True
      firewall-driver: openvswitch
      dns-servers: "8.8.8.8"
      enable-local-dhcp-and-metadata: true
      data-port: 'br-data:eno4'
      enable-sriov: True
      sriov-device-mappings: 'physnet_sriov:eno5'
      sriov-numvfs: 'eno5:8'

After the deployment, without any error, on one of the hosts:
ip link show eno5
16: eno5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 04:09:73:ca:93:dc brd ff:ff:ff:ff:ff:ff

We can see that no VF has been created.
To work around that issue, it is necessary to trigger a config-changed.
For example:

juju config neutron-openvswitch sriov-numvfs=''
juju deploy bundle.yaml

After that, we can see the created VFs:
ip link show eno5
16: eno5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 04:09:73:ca:93:dc brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off
    vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off
    vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off
    vf 3 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off
    vf 4 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off
    vf 5 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off
    vf 6 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off
    vf 7 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

Nicolas Pochet (npochet)
description: updated
Revision history for this message
James Page (james-page) wrote :

Hint:

    if charm_config.changed('sriov-numvfs'):

is probably the cause as this config option does not change between install and config-changed running.

Changed in charm-neutron-openvswitch:
assignee: nobody → Sahid Orentino (sahid-ferdjaoui)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-neutron-openvswitch (master)

Fix proposed to branch: master
Review: https://review.openstack.org/639121

Changed in charm-neutron-openvswitch:
status: New → In Progress
Revision history for this message
Alvaro Uria (aluria) wrote :

Hi, I copy here the review added in Gerrit:

I find Gerrit change 639121 dangerous. configure_sriov will set sriov_numvfs to 0, then N on every config-changed or neutron-plugin-relation-changed hook. This means that instances using VFs will lose connectivity in case any change is done via Juju.
https://github.com/openstack/charm-neutron-openvswitch/blob/bd1cc362f139f4854872a7eb87a62c4fc8273dbf/hooks/neutron_ovs_hooks.py#L99:L124

Number of VFs should only be changed when an interface goes from "down" operstate to "up" (after a reboot, or manual ip link set). Alternatively, an action could be run to force the setting.

In xenial, we currently use the following shell script (/etc/network/if-up.d/99vnf_sriov):
"""
if [ "$IFACE" = "eno2" ]; then
    cat /sys/class/net/eno2/device/sriov_totalvfs > /sys/class/net/eno2/device/sriov_numvfs
fi
"""

So, change is only applied on ifup. I think a possible approach could be to add a config param "action-managed-sriov-numvfs", which will allow changing the "ifup" script but won't apply the change live until an action is run. If the config param is disabled, then change would also be applied as in the proposed change.

tags: added: canonical-bootstack
Revision history for this message
Peter Sabaini (peter-sabaini) wrote :

Wishlist item (expanding on what Alvaro said in #3), it would be great to have integration tests that check link health of a running instance for various charm operations

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-neutron-openvswitch (master)

Reviewed: https://review.openstack.org/639121
Committed: https://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/commit/?id=381a3b1a3317fa648f82357a9bce0adccb8bec18
Submitter: Zuul
Branch: master

commit 381a3b1a3317fa648f82357a9bce0adccb8bec18
Author: Sahid Orentino Ferdjaoui <email address hidden>
Date: Mon Feb 25 14:54:48 2019 +0000

    hooks: fix initial sriov configurations

    To configure SRIOV devices it was expected that the 'sriov-numvfs'
    config option to be changed but during an initial setup this not
    happens.

    In this commit we remove the condition but add a logic in
    PCINetDevice to avoid reconfiguring PF devices if not necessary.

    Change-Id: Ib8232b29f76ca7e25e1cd835d5e31a276000f1d4
    Closes-Bug: #1817079
    Signed-off-by: Sahid Orentino Ferdjaoui <email address hidden>

Changed in charm-neutron-openvswitch:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-neutron-openvswitch (stable/18.11)

Fix proposed to branch: stable/18.11
Review: https://review.openstack.org/641946

James Page (james-page)
Changed in charm-neutron-openvswitch:
milestone: none → 19.04
David Ames (thedac)
Changed in charm-neutron-openvswitch:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on charm-neutron-openvswitch (stable/18.11)

Change abandoned by "Felipe Reyes <email address hidden>" on branch: stable/18.11
Review: https://review.opendev.org/c/openstack/charm-neutron-openvswitch/+/641946
Reason: 18.11 is EOL

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.