| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The original implementation supported a strictly numeric mapping scheme
(e.g. nic1, nic2) that could misbehave if an active NIC was not listed in the
user's mapping file. This change fixes the misbehavior, and enhances the
feature by not requiring NIC aliases follow the numeric mapping scheme. This
allows the user to choose meaningful names for the NIC aliases.
NIC mapping now happens in two steps:
1) Process any user supplied mappings
- NIC alias does not need to follow the numeric "nicN" scheme
- Existing validation rules apply: mappings for inactive NICs are ignored
(but logged), and duplicate mappings are rejected
2) Generate default mappings as needed
- Only applies to active NICs that aren't already mapped
- Follows the numeric scheme (nic1, nic2) using the NIC number based on
the list of active NICs
- No default mapping is assigned if another NIC is already using that
numeric alias
Change-Id: I6943623a51702349f6a7dcf2de8a8429078a3ab0
Closes-Bug: 1612723
|
|
This adds the option to permanently rewrite the configuration so the
aliases are used instead of the system name. This is useful where
you have a variety of hardware and you want to have consistent device
naming accross all platforms - this allows you to essentially rename
the interfaces permanently so they match the abstracted nicN names.
Note, this needs to be run with --cleanup or the old (now conflicting)
configs will still be in place, and it may require a reboot before
the changes are fully applied.
Change-Id: I5af146e764b72c4beaa41c549fabff0af8802152
|
|
Currently there's a fixed mapping between abstracted interface
names (nic1, nic2 etc) and the underlying biosdevname for the
device.
In many cases, this mapping based on system enumeration is
sufficient, but in some cases, particularly when you perform
detailed pre-deployment discovery of interfaces, you may wish
to alter the mapping independently of the config (e.g if the
config is in a heat template, and the discovery data is
provided at runtime).
So this adds a -m option to os-net-config, which enables a
mapping file to be provided, such that specific interfaces
may be mapped to their abstract names based on knowledge of
the devices or the networks they are connected to.
The mapping file has the following format, where em1 and em2 are
device names as detected by the OS (e.g biosdevname):
interface_mapping:
nic1: em2
nic2: em1
Or you can use the device MAC instead:
interface_mapping:
nic1: 12:34:56:78:9a:bc
nic2: 12:34:56:de:f0:12
Change-Id: I93e6d3ed733244834bb3c2126c91db705b4d9167
|
|
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.
|
|
Add some initial objects for interfaces, routes and addresses.
|
|
Initial commit of the project layout
|
Alan Bishop
Steven Hardy
Dan Prince