All indication in CI is that Centos Stream9's use of dhclient
appears to point to compatability issues when interacting with
dnsmasq. However, this doesn't appear to be the issue with the
internal dhcp client. As such, lets constraint the RH default
so that it no longer applies to Centos 9-stream.
I've also added a documentation entry for DIB_DHCP_CLIENT which
was previously undocumented.
As an aside, I've already reached out to RH's NetworkManager team
regarding this, but root cause is not entirely understood at this
point.
Change-Id: I235f75b385a8b0348c8fe064038c51409f8722c4
Story: 2010109
Task: 45677
This reverts commit 8401290976.
We are reverting this because some users may want to use predictable
device names and may not even use Debian. However, after some
investigation we have found a couple of bugs in dhcp-all-interfaces on
Debuntu distros. The parent change corrects those bugs. Additionally new
Linux kernels emit "move" events to udev when interfaces are renamed to
their predictable name. Support this "move" in the dhcp-all-interfaces
udev rules. Making these changes appaers to produce functional images
for Debian users using predictable device names. If predictable device
names are not desired turning them off is straightforward and release
notes are updated to give users the info they need to do that outside of
this element.
Change-Id: I125f1a0c78a103b51bda961528c3e66c345bf604
Co-Authored-By: Clark Boylan <clark.boylan@gmail.com>
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>
There are two issues with dhcp-all-interfaces on debuntu interfaces
addressed here. First is the path to dhclient lease files is
/var/lib/dhcp not /var/lib/dhclient. Second there is a missing newline
in the ENI interface file which causes a parse error.
Change-Id: Ice83e0d49a4234301dc12daf828ba80fef414cdb
The dhcp-all-interfaces element does not work with the predictable names
scheme, fallback to the persistent names scheme as workaround.
Bug: 1960301
Change-Id: I117964a60615a5b7e9984f52f02cd018d1a48ed0
NetworkManager is quite capable to do automatic
interface configuration. NetworkManager will by default
try to auto-configure any interface with no configuration.
It will use DHCP for IPv4 and Router Advertisements to
decide how to initialize IPv6.
It will most likely do it just as good, or better than the
dhcp-all-interfaces.sh script.
Since dhcp-all-interfaces clean out all ifcfg files in
60-remove-cloud-image-interfaces it means NetworkManager will
by default attempt auto configuration for all interfaces.
This change add's and environment variable:
DIB_DHCP_NETWORK_MANAGER_AUTO (default: false)
When DIB_DHCP_NETWORK_MANAGER_AUTO is set to `true` only the
NetworkManager config will be written. The dhcp-all-interfaces
service will not be installed. Hence dhcp-all-interfaces will
not write any config files, allowing NetworkManager to just do
it's thing.
Change-Id: Id6f8d6aaaf52a78175bb6c065ec88274c364834e
This change will remove any existing interface configurations in the image. They are not necessary
and could interrupt with deployments. In any case they should not exist if we use
dhcp-all-interfaces element.
Change-Id: I35a4b5ea6e2315de3b0d9f8353ac2b6f4b995697
Provide ability to run dhcp client on VLAN interfaces created on
top of an Ethernet interface. See also
<https://storyboard.openstack.org/#!/story/2008298>`__ for further details.
Change-Id: Ic3ffd7b8e23b1e996cfe6c79ce0ff47e521f30be
NetworkManager takes a distinctly differnet network management
approach and the bulk of the dhcp-all-interfaces code is largely
targetted at distribution specific configuration. Some which may
or may not override settings, or only partially assert desirable
settings.
As such, we need to set appropriate configuration, such as the
correct client to be used, and timeouts based upon user supplied
settings.
By default this change sets the client to be dhclient on redhat
styled machines, as the packaging default, while it works for
ramdisk usage, it does not reset the interface between retries,
which can be critical if the infrastucture operator is attempting
to configure LACP trunks to the end node.
Change-Id: I0e0cfbdbf7ef2b2861b934ccd7dab9d83a35c8f0
Story: 2008001
Task: 40648
The ndisc6 package is not yet available in EPEL 8.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1779134
Until the package is available set the pkg-map to "" for
the ndisc6 package when distro is redhat and install the
package using || true in the element script instead so
that CentOS 8 build's do not fail because of the missing
package.
Once the package is in EPEL 8 this change can be reverted.
Related-Bug: #1754219
Change-Id: Icd4bad8852ce5ba40fb0e7b0d335191efbe88c67
If rdisc6 is available, a node using this element will loops until
DIB_DHCP_TIMEOUT is reached because of a missing 'break' when rdisc6
return code is 0.
This will mark the dhcp-interface@.service unit as failed (because it
has the same timeout) and not bring any network interface online.
Change-Id: I034dcda94d765f236950ebcbee36789f5bdc515f
Closes-Bug: #1854717
Signed-off-by: Hervé Rousseau <hroussea@cern.ch>
When the rdisc6 utility is available probe for router
advertisement. configure eni and rhel-netscripts interfaces
to do IPv6 address configuration according to the flags
in the RA recived from the router.
The systemd service file timeout is DIB_DHCP_TIMEOUT * 2,
so that DHCPv4 can timout, and dhcpv6 run before the service
times out.
Retries are commented in dhclient.conf, without it we end up
trying DIB_DHCP_TIMEOUT * 60 before the client move on to
IPv6.
WHEN:
Stateful address conf. : No
Stateful other conf. : No
THEN:
Do not run dhclient at all, autoconfiguration via
SLAAC only.
WHEN:
Stateful address conf. : No
Stateful other conf. : Yes
THEN:
Run "dhclient -6 -S", The ``-S`` option makes the
dhcp client not request an address, only other
options such as DNS servers and NTP servers from
DHCPv6 server.
WHEN:
Stateful address conf. : Yes
Stateful other conf. : Yes
THEN:
The dhcp client should request an address _and_ other
options such as DNS servers and NTP servers from
DHCPv6 server.
NOTE: No IPv6 support added for suse-netscripts
Closes-Bug: 1754219
Change-Id: Icdc79875c33f894ab7eaec8afdfb33a731efff99
This patch adds an expected semicolon to an end of statement in
dhclient.conf for dhcp-all-interfaces element. Without this fix, an
error occurs when an image is booted with a message,
'semicolon expected.'.
Change-Id: I8311dbc67cc2815223111da01e7a7517c7d6f059
According to http://bit.ly/2HA4oDO and
the official Ubuntu manual
http://manpages.ubuntu.com/manpages/xenial/man5/interfaces.5.html
source-dir support has been removed from Ubuntu >= 16.04/Xenial
Once an image is generated and booted, moving the dhcp interface(s)
declaration(s) from /etc/network/interfaces into specific subentries
of /etc/network/interfaces.d and calling 'service networking restart'
just make your instance unreachable and all interfaces are left
unconfigured.
This patchset fixes this issue
Change-Id: I6b6b99c81490c874c5db5405c2fbf3c180c87464
On initial boot when networking is brought up by cloud-init this
is the timeout that dhclient adheres to. Centos configures
"timeout 300" (for an EC2 bug) in their cloud image, which results
in a 5 minutes delay to boot in cases where no dhcp available (e.g. IPv6
SLAAC). To reduce this boot delay and to provide consistency with
places where we have set other dhcp timeouts set this to DIB_DHCP_TIMEOUT.
Change-Id: I119a002070501c3dfe7c6730b07ee25f422b85b0
Related-Bug: #1758324
In slow networks like Infiniband it takes much time for the
interface to get the carrier. This patch enables this service
to run more then 20 seconds and limited by DIB_DHCP_TIMEOUT.
Change-Id: I8a6015567ac25e37b5a5aba4b1fda71170cc144a
In Ubuntu/Debian, the default dependencies cannot be relied
upon as we enter into a cyclical dependency relationship which
prevents the unit from starting.
Added the required configuration to the systemd unit file.
This issue has also been observed in glean[0], which has a nearly
identical unit file for interface start-up.
[0]: https://review.openstack.org/#/c/485748
Closes-Bug: #1708685
Change-Id: I23ac9510d1a21c7073bd33f76ba66fa04a8be035
Currently we have all our elements and library files in a top-level
directory and install them into
<root>/share/diskimage-builder/[elements|lib] (where root is either /
or the root of a virtualenv).
The problem with this is that editable/development installs (pip -e)
do *not* install data_files. Thus we have no canonical location to
look for elements -- leading to the various odd things we do such as a
whole bunch of guessing at the top of disk-image-create and having a
special test-loader in tests/test_elements.py so we can run python
unit tests on those elements that have it.
data_files is really the wrong thing to use for what are essentially
assets of the program. data_files install works well for things like
config-files, init.d files or dropping documentation files.
By moving the elements under the diskimage_builder package, we always
know where they are relative to where we import from. In fact,
pkg_resources has an api for this which we wrap in the new
diskimage_builder/paths.py helper [1].
We use this helper to find the correct path in the couple of places we
need to find the base-elements dir, and for the paths to import the
library shell functions.
Elements such as svc-map and pkg-map include python unit-tests, which
we do not need tests/test_elements.py to special-case load any more.
They just get found automatically by the normal subunit loader.
I have a follow-on change (I69ca3d26fede0506a6353c077c69f735c8d84d28)
to move disk-image-create to a regular python entry-point.
Unfortunately, this has to move to work with setuptools. You'd think
a symlink under diskimage_builder/[elements|lib] would work, but it
doesn't.
[1] this API handles stuff like getting files out of .zip archive
modules, which we don't do. Essentially for us it's returning
__file__.
Change-Id: I5e3e3c97f385b1a4ff2031a161a55b231895df5b
