Fuel for OpenStack

[TestImpact] fuel-qa and dynamical nic naming

Bug #1537751 reported by Aleksey Zvyagintsev
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Confirmed
Medium
Fuel QA Team
Fuel for OpenStack 10.0
Mitaka
Won't Fix
Medium
Fuel QA Team
Fuel for OpenStack 9.0
Newton
Confirmed
Medium
Fuel QA Team
Fuel for OpenStack 10.0

Bug Description

Since fuel-release 8.0, fuel swithced to net.ifnames nic naming schema
which has been implemented via udev rule[0]:
The main problem, that different HW\virt drivers send different row-structure of nic.
In general udev info looks like:
#### Real HW
udevadm info --query=property -p /sys/class/net/eno1
DEVPATH=/devices/pci0000:00/0000:00:03.0/0000:04:00.0/net/eno1
ID_BUS=pci
ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
ID_MODEL_ID=0x1521
ID_NET_NAME_MAC=enx0cc47a0fcf44
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_PATH=enp4s0f0
ID_PCI_CLASS_FROM_DATABASE=Network controller
ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_VENDOR_ID=0x8086
INTERFACE=eno1
net.ifnames=1
...

#### OR for virtio
udevadm info --query=property -p /sys/class/net/eth0
DEVPATH=/devices/pci0000:00/0000:00:06.0/virtio3/net/eth0
ID_BUS=pci
ID_MODEL_FROM_DATABASE=Virtio network device
ID_MODEL_ID=0x1000
ID_NET_NAME_MAC=enx6402bd95a8d1
ID_PCI_CLASS_FROM_DATABASE=Network controller
ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
ID_VENDOR_FROM_DATABASE=Red Hat, Inc
ID_VENDOR_ID=0x1af4
IFINDEX=5
INTERFACE=eth0
net.ifnames=1

So, as you can see, virtio driver did't contain
ID_NET_NAME_ONBOARD or
ID_NET_NAME_SLOT or
ID_NET_NAME_PATH
row, which needed for correct work of 80-net-name-slot.rules.

All this realize that nic name depend-on nic driver- which system use.

Otherwise, own fuel-qa scripts using hard-coded naming [1]

I propose to add dynamical naming support for fuel-qa (or something other then hardcode)
(We can fetch any needed information from devops driver
like mac for interface, and then find this interface-name on bootstrapped node. ))

(Other soluthion, which will be investigated - possibility to add ID_NET_NAME_MAC like another one name-rule)

[0] https://github.com/openstack/fuel-agent/blob/master/contrib/fuel_bootstrap/files/trusty/lib/udev/rules.d/80-net-name-slot.rules#L10-L12
[1] https://github.com/openstack/fuel-qa/blob/master/fuelweb_test/settings.py#L35-L42

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

See original description
Aleksey Zvyagintsev (azvyagintsev)
description: updated
Aleksey Zvyagintsev (azvyagintsev)
tags: added: fuel-dev-tools fuel-qa tech-debt
Changed in fuel:
status: New → Triaged
Aleksey Zvyagintsev (azvyagintsev)
Changed in fuel:
assignee: nobody → Fuel QA Team (fuel-qa)
Ksenia Svechnikova (kdemina)
Changed in fuel:
milestone: none → 8.0
milestone: 8.0 → 9.0
Nastya Urlapova (aurlapova)
summary: - fuel-qa and dynamical nic naming
+ [TestImpact] fuel-qa and dynamical nic naming
Changed in fuel:
importance: Undecided → High
slava valyavskiy (slava-val-al)
Changed in fuel:
status: Triaged → Confirmed
Ivan Ponomarev (ivanzipfer)
tags: added: area-qa
Revision history for this message
Artem Panchenko (apanchenko-8) wrote :

Since we don't use 'virtio' driver for tests (see bug #1433593) and with 'e1000' driver hardcoded interfaces names are always correct, this bug doesn't look as 'High' for me. But since we are going to use fuel-qa for bare-metal testing, we need to implement dynamic NICs naming in 9.0 or next releases.

Changed in fuel:
importance: High → Medium
no longer affects: fuel/8.0.x
Revision history for this message
Alexandr Kostrikov (akostrikov-mirantis) wrote :

>'I propose to add dynamical naming support for fuel-qa (or something other then hardcode)'
That decision masks real issue with a loose patching.

From end-user perspective interfaces should be predictable and consistent on all devices.
When user deploy cluster on 'eth0' as fuelweb-admin and 'eth1' for other networks he has to be sure that devices are inserted in particular order.

We can create utility for end-users and fuel-qa to map interfaces to network via whatever possible, but hide that in fuel-qa hacks is wrong.

>#### OR for virtio
VIrtio is not relevant to fuel-qa.

Mark it as invalid until clear view on end-user experience or `non-hack` proposal.

Changed in fuel:
status: Confirmed → Invalid
Revision history for this message
Alexandr Kostrikov (akostrikov-mirantis) wrote :

Also, we can reopen it for 'we are going to use fuel-qa for bare-metal testing' to track progress.

Revision history for this message
Aleksey Zvyagintsev (azvyagintsev) wrote :

@akostrikov
>> That decision masks real issue with a loose patching.
>> From end-user perspective interfaces should be predictable and consistent on all devices.
 It's not and end-user issue at all.
Exactly net.ifnames guarantee predictable nic naming- not old-style ethX .
For more information - please read last link from issue description.

Issue about 'host-to connect fuel-qa interface mapping(which currently hard-coded ) and real hardware nic-naming'

Revision history for this message
Alexandr Kostrikov (akostrikov-mirantis) wrote :

@alexz thanks for clarification. I am reopening it as 'we are going to use fuel-qa for bare-metal testing'.

Possibly, it will be marked as duplicate or edited by fuel-qa framework team.

Changed in fuel:
status: Invalid → Confirmed
Revision history for this message
Albert Syriy (asyriy) wrote :

Guys, (it shouldn't concern me, but) IMHO it's not a good idea to stick to the interfaces names in (your) tests, better stick to the MAC addresses and gather the information about interfaces names on the MAC addresses basis.
Otherwise the tests could be unexpectedly broken by changes made in udev rules (by CentOS or Ubuntu), which you will not be even aware about.

@akostrikov: I strongly believe, the time spent for writing a small function (gathering an interface name from the MAC address of an interface) would pay off and saving a lot of time in future.

Regards,
Albert

Revision history for this message
Alexandr Kostrikov (akostrikov-mirantis) wrote :

@asiry
>I strongly believe, the time spent for writing a small function
 Yes, that function can help us to avoid many problems, but it can lead to inconsistency for end-user.
I think, we should add a person with end-user experience - how they going to use predictable interface naming schema in fuel to deploy large amounts of servers.
I will try to reach someone with support experience to get real data on that topic.

Nastya Urlapova (aurlapova)
tags: removed: fuel-qa
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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