Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Currently os-net_config will map nics from a user-supplied mapping file
only if the nic is active (operstate = up). This can cause problems
if a nic is in a bond and one of the bond's nics has no carrier.
This fix will map the nic from the mapping file if the nic is defined
on the system, regardless of the operstate status.
The fix implements a new function to return a list of available nics
(no check of operstate) for use if a mapping file is supplied. The
list of active nics must still be used in the default case when
numbering nics (no mapping file supplied). There is also some
cleanup to check if a user-supplied mac is in the mapping file before
attempting to convert the mac to a nic.
Change-Id: Ia5d8c8b49b7ac0b51ee42a754f06e5e53587a5f6
Closes-Bug: 1679787
|
|
Vector Packet Processing (VPP) is a high performance packet processing
stack that runs in user space in Linux. VPP is used as an alternative to
kernel networking stack for accelerated network data path. VPP uses DPDK
poll-mode drivers to bind system interfaces rather than kernel drivers.
VPP bound interfacees are not visible to kernel networking stack and
therefore require different configuration steps in os-net-config.
VPP interface will be used in Openstack by either Neutron ML2 driver
networking-vpp as an alternative to OVS, or by Opendaylight SDN
controller with Honeycomb agent.
This patch adds interface configuration support to os-net-config.
The kernel nic specified to be VPP interface type will be bound to
VPP with a DPDK poll-mode driver. Note that os-net-config will only
configure those settings that affect interface binding, all other
configurations for VPP will be configured throught TripleO Heat
Templates.
Implements: blueprint fdio-integration-tripleo
Change-Id: Iebb40b7c5b252c51e86b6f44bcf36ed206101390
Signed-off-by: Feng Pan <fpan@redhat.com>
|
|
SR-IOV Virtual Functions will be present as an interface in the
directory '/sys/class/net'. As these are virtual interface created
during the deployment process, it has to be ignored in the nic
numbering logic.
Closes-Bug: #1653097
Change-Id: I118a7314d496b531c52be45521d393123cdfe915
|
|
When using mapping file with mac address, mapping logic will try
to fetch the mac address of the interface, which will fail. Storing
the mac address also in the DPDK mapping file so that we can satisfy
mapping logic.
Closes-Bug: #1619330
Change-Id: I92ba7f589c8d848feb083f07c3f937b50aca388e
|
|
* os-net-config is called multiple times during the deploy.
Once the interface is bound to a driver, it will not be
listed for ethtool to get the pci address, which will
through exception. Handled this exception.
* Stored the DPDK bound nic configs at '/var/lib/os-net-config/
dpdk_mappings.yaml' file to emulate the same nic numbering
after the nic has been bound to the DPDK driver.
Partial-Bug: #1619330
Change-Id: I6b1e45003f851f1fcf5b8730890c75331e8d0f8f
|
|
Add support in os-net-config for DPDK ports and OVS user bridges,
and implement parameters which will be set by the TripleO Heat
Templates when using TripleO.
Implements: blueprint tripleo-ovs-dpdk
Change-Id: Id4a23ced28b92a642c180a35c55080e5f4e2e05d
|
|
This small change fixes a serious bug in os-net-config which made
mapping NICs by MAC address not idempotent if Linux bonds were used.
The first time os-net-config runs, it sees the MAC address of each
interface, then it sets up the bond. On subsequent runs, any
non-primary interfaces have taken the MAC address of the primary
interface in the bond. At this time, they all show the same MAC
address. This causes the mapping to fail, and it appears that
the system has fewer matching interfaces than it had before.
The impact of this bug is that bonding doesn't work for
anyone doing mapping by MAC address. This is known to be affecting
installations with a particular 3rd-party Neutron plugin vendor.
This change simply looks for the permanent hardware address under
the bonding_slave directory, if it exists.
Change-Id: I5b0087370f74ecc319d2285b0f9f5f3dd951dbc2
|
|
Occassionally I've found myself debugging os-net-config's behavior
related to detecting active nics. This adds a little debugging output to
help see what's going on in the ordered_active_nics function.
Change-Id: If7ea010071d2253b29aaaabb242690ea5fbfb165
|
|
The previous check for an interface operstate only looked for the
literal "UP" in caps, but in my environments I'm seeing operstate
returned as "up" in lower-case, which causes the _is_active_nic
check to fail incorrectly. Example:
[root@overcloud-controller-0 heat-admin]# cat /sys/class/net/eth0/operstate
up
In this environment os-net-config is failing with the exception
in the linked bug.
Change-Id: I85c2d074ce43673c691523ca146ff7cdfdf1c7ca
Closes-Bug: 1569403
|
|
Fixes lp bug 1555669
Currently _is_active_nic performs multiple checks to see if a link is live.
However some hardware such as Ethernet over USB devices fulfil this criteria.
This causes tripleo deployments to fail if automatic interface naming is used.
We can therefore use operstate to determine if the link is actually up.
https://www.kernel.org/doc/Documentation/networking/operstates.txt
This patch implements this.
Implements: better link state detection
Closes-Bug: #1555669
Change-Id: I0bdd0c987f4f177935df4f7cdcc70f4d99c988a5
Signed-off-by: Christopher Brown <snecklifter@gmail.com>
|
|
The detailed bug description is at
https://bugs.launchpad.net/os-net-config/+bug/1537330
Since kilo, os-net-config starts to support linux bond.
However, the addr_assign_type value of an active member
interface of a linux bond is 3, but not 0. The consequence
of this problem is that the linux bond member links are
never considered as active, this further messes up the
nicX to interface name mapping.
This change checks if device directory exists, instead
of checking the addr_assign_type value. This directory
exists only when the interface is an actual physical
interface.
Change-Id: I8e4c95a2efa809fd236b07cbce1b81a2e774f858
|
|
This way device eth10 is after eth9, and not directly after eth1
Change-Id: I81eba97cccf6c4f314f9037d16ee1f244dbade02
Closes-Bug: #1482818
|
|
On certain systems, the embedded NICs appear as eno1, eno2, etc.
This patch adds 'eno' to 'em' and 'eth' as interface names that
should be considered embedded NICs.
Change-Id: Icc49596573bdbb8af25f934a647f0a2ab82adaa5
|
|
Update the utils.get_file_data method so that it doesn't log
errors if a file doesn't exist.
|
|
Implements a new active NIC abstraction and naming convention
that allows nic1, nic2, etc. to be translated to actual (active)
network device names like em1, em2 (or eth0, eth1).
This includes some logic to map ordered active nics to the
nic1, nic2 naming scheme. Embedded nics are always listed
first (in sort order) followed by any other active Nics
on the system.
With the new code:
{"type": "interface", "name": "nic1" }
is automatically translated (internally) to:
{"type": "interface", "name": "em1" }
This works for all top level "interface" devices, vlans, bonds, and
bridges alike. For vlans the 'device' name is translated instead
of the device name per vlan object conventions.
|
|
Adds support for a new 'primary' interface option exposed via the
object model and JSON parsers which can be used to force the
MAC address on a bridge. Only one interface on a given
bridge (or bond) may be set as the primary interface.
Also, update the ifcfg and eni providers so that they use
OVS_EXTRA (or ovs_extra) to pin the mac accordingly.
|
|
|
|
|
|
Adds an apply function to the ifcfg implementation
which:
1) Shuts down existing interfaces w/ ifdown
2) writes new interfaces config files (routes too)
3) Starts up new interfaces w/ ifup
|