NIC no more belongs to bridges after server reboot

[Alexander Rubtsov]

MOS: 7.0
Feature: Reduced footprint

Virtual machines (which are hosted by a node with "virt" role) lose their network configuration after reboot
If we use 1 NIC for mapping of all logical networks (without bondings), after reboot this NIC will disappear from bridges (which it is supposed to be in)

To make this settings permanent, the corresponding configuration files, in the /etc/network/interfaces.d/ directory, should be configured according to the specifications:
https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-switch.README.Debian

For example:
auto eth2
iface eth2 inet manual
ovs_bridge br-fw-admin
ovs_type OVSPort

[Alexander Rubtsov (arubtsov)]

sla2 for 7.0-updates

[Bogdan Dobrelya (bogdando)]

Please note that according to the design spec, the VMs are "fire and forget". There was healing/monitoring by design

[Bogdan Dobrelya (bogdando)]

See https://review.openstack.org/#/c/169676/30/specs/7.0/reduced-footprint.rst for details

[Alexander Rubtsov (arubtsov)]

From the feature specification:
"Virtual machines will be treated by Fuel as standard bare metal servers. Fuel will allow only to start/deploy VMs. User should take care about VMs maintenance. We will deliver fire-and-forget solution"

I think that making NIC a permanent part of the corresponding bridge is related to proper network configuration rather than maintenance

Currently, use cases that include hosts reboot are blocked and require manual reconfiguration
Could you please revise the implementation?

[Bogdan Dobrelya (bogdando)]

Yes, I believe the decision should be to drop this experimental feature as a set of bash scripts and reimplement it from the scratch but using Nova API to spawn and LCM instances

[slava valyavskiy (slava-val-al)]

I have checked the following case:
1. I have used network template
2. I have used ovs provider for br-fw-admin
3. I have connected physical interface directly into br-fw-admin bridge

As result of application netconfig task I get appropriate network configuration is in place.

root@node-3:~# cat /etc/network/interfaces.d/ifcfg-br-fw-admin
auto br-fw-admin
allow-ovs br-fw-admin
iface br-fw-admin inet static
ovs_ports eth0
address 10.20.0.191/24
gateway 10.20.0.2
ovs_type OVSBridge

[slava valyavskiy (slava-val-al)]

I'm checking ovs-to-ovs network configuration. Right now, I guess this bug is duplication of https://bugs.launchpad.net/fuel/+bug/1495534

[slava valyavskiy (slava-val-al)]

I was able to reproduce issue for following network configuration(part of network template):
###
        transformations:
        - action: add-br
          name: br-fw-admin
          provider: ovs
        - action: add-br
          name: br-mgmt
          provider: ovs
        - action: add-patch
          bridges:
          - br-fw-admin
          - br-mgmt
          mtu: 9000
          provider: ovs
          vlan_ids:
          - 100
          - 0
        - action: add-port
          bridge: br-fw-admin
          name: <% if1 %>
###

[slava valyavskiy (slava-val-al)]

It seems that approach described in bug's description is correct. Currently, l23network generates following configuration for physical ports:
root@node-3:~# cat ifcfg-eth0
auto eth0
iface eth0 inet manual

but, it should look like(works for me):
root@node-3:~# cat /etc/network/interfaces.d/ifcfg-eth0
allow-br-fw-admin eth0
iface eth0 inet manual
ovs_type OVSPort
ovs_bridge br-fw-admin

[slava valyavskiy (slava-val-al)]

It seems that l23 network module should be fixed to handle specific type of port for ovs provider:
###
        - action: add-port
          bridge: br-fw-admin
          name: <% if1 %>
          provider: ovs
###

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/7.0
Review: https://review.openstack.org/266623

[Anton Matveev (amatveev)]

sla1 for MOS7.0

[OpenStack Infra (hudson-openstack)]

Change abandoned by Valyavskiy Viacheslav (<email address hidden>) on branch: stable/7.0
Review: https://review.openstack.org/266623