| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Bumps the version of hacking to match that in global-requirements.txt.
Change-Id: I7bb98dc773ce821b025d534f537f1a1704a50f9e
Closes-bug: #1566463
|
|
|
|
This change generates /etc/sysconf/network-scripts/ifcfg-* for ivs.
It also generates /etc/sysconf/ivs configuration file for ivs.
It supports only RedHat at this point.
Indigo Virtual Switch (IVS, https://github.com/floodlight/ivs)
is a virtual switch for Linux. It is compatible with the KVM
hypervisor and leveraging the Open vSwitch kernel module for
packet forwarding. There are three major differences between
IVS and OVS:
1. Each node can have at most one ivs, name is not required.
2. Bond is not allowed to attach to an ivs. It is the SDN
controller's job to dynamically form bonds on ivs.
3. IP address can only be statically assigned.
Change-Id: I276d736794d123405de793c2a4eb2c1ee55a0fad
|
|
The usage of assertEqual(True/False, ***) should be changed
to a meaningful format of assertTrue/False(***).
Change-Id: Ic15b6ebff7f050c1d516d9d680f362609803da4c
Closes-Bug:#1512207
|
|
This patch adds support for Linux Bridges to os-net-config. This is
done completely with ifcfg files, brctl is not used directly.
Hierarchy is preserved, so a Linux Bridge may have a Linux Bond
as a member, which in turn may have multiple interfaces as members.
This changeset has been updated to include a more specific example
for Linux bridge configuration (that doesn't combine bridging and
bonding).
This change depends on the change to add support for Linux Bonds.
Change-Id: I1ddacd514b02af30139a868071d82cde19b1f946
|
|
This change adds support for Linux Bonding to the impl_ifcfg
in os-net-config. This change adds support for configuring Linux
Bonds using the Bonding module rather than Open vSwitch. Most of
the options for Linux Bonds are the same as OVS, with the exception
of bonding_options instead of ovs_options.
Change-Id: If8c6de1554234277843de9fac58536dd5b0a941b
|
|
Adds in the ability to optionally configure DNS
server settings via the ifcfg file formats.
The dns_servers JSON is an array which currently
supports either 1 or 2 DNS servers (per limitations
of the ifcfg format).
Change-Id: I9edecfdd4e1d0f39883b72be554cd92c5685881d
|
|
This patch adds an optional flag that can be used to
pass in args for dhclient when using DHCP.
This use case for this is to be able to control which
DHCP options dhclient listens for and we can thus
disable specific options (like routing) for some
network configurations.
Change-Id: Ic21de0615ea0ef304843c55cc5abe43cb1771169
|
|
When multiple interfaces are configured with DHCP, and more than
one interface receives a gateway from the DHCP server(s), the
resulting default gateway on the system is unpredictable. This
change adds the "defroute" boolean to the configuration syntax
for os-net-config. Any interface type may be marked so that the
gateway received from the DHCP server will not be eligible as a
default gateway for the system. This only works for ifcfg files,
/etc/network/interfaces lacks an equivalent option.
Change-Id: Id775f3506b2ec60c9a2833efd49fb8319151c00d
Closes-Bug: 1449288
|
|
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.
|
|
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 a from_json static method to all objects.
Also adds a top level object_from_json function that
can be used for all the interface and bridge types.
(everything except addresses and routes). This should
be useful for wiring processing JSON from the CLI.
|
|
Ifcfg formatted persistence for interfaces and routes.
|
Dan Prince
Jenkins
xinwu
Swapnil Kulkarni (coolsvap)
Dan Sneddon
Steven Hardy