skip deconfiguring interfaces
Testing Done: Tested 'service networking stop' during system reboot and shutdown
(cherry picked from commit ac231e966a04eb78153d9b53f0d236a149c7bba5)
(cherry picked from commit 496b5b0176df9d3be05021c93e917afb195ee799)
Testing Done: tested master and 2.5_br images with testifupdown2 suite and hand tested
This patch creates a json defaults file upon bootup
(which can be overridden by customer configs in /etc)
which the ethtool module in ifupdown2 will consult
when "link-x" configs are removed in order to restore
them to the initial settings used by the switch.
(cherry picked from commit 8388664f5a5a85f2a813cafbf40ac92d7b86f4bf)
Conflicts:
packages/cl-utilities/dist-packages/cumulus/portconfig.py
packages/cl-utilities/usrlib/update-ports
tests/tests/smoke/testifupdown2.py
Testing Done: Tested with test case in the bug and other orders
kernel(upstream and us) does not seem to honor the vidinfo flags
during the deletes. Hence, this reordering becomes necessary.
tested with the example in the bug and also some other examples.
code wise this combines two existing methods but leaves the two existing methods
around for future use. Will remove them if they become completely
unnecessary.
(cherry picked from commit 992906e0771b7415cbd8c03563a99a8f050415bd)
(cherry picked from commit 1ad488b44e1a9a0e059765e8ee4a19164b386dfe)
down all changed interfaces
Testing Done: Tested man page
(cherry picked from commit 93ecf73b22d317dcf2a0924030f34f008fc25c33)
(cherry picked from commit 73d846c447d575a72822abd5ac5d5d758e9686e5)
sections for that interface changed
Testing Done: tested ifreload with new iface section
problem stmt:
if the user adds a new section for an existing interface, I mark the
interface for down.
Basically the below:
if len(newifaceobjlist) != len(lastifaceobjlist):
ifacedownlist.append(ifname)
continue
You rarely need to add a new section to the interfaces file. It is not
recommended even by the user guide.
sankaran was trying to add a new address. Which he could have added to
the same iface section.
But, looking at his trivial example, i am thinking of not marking an
interface for down if the user merely tried to add a new section to an
existing interface
(cherry picked from commit 65c62c02981cf6e2677b18c0aafcb3f2bd737b1b)
(cherry picked from commit 4453b1921fc3f8e959131cb5e1b9e79e0433cc08)
Testing Done: build and tested man page
(cherry picked from commit 540aa30332a3c49e8a2be2c3975a3a24dbbf1209)
(cherry picked from commit 9426b13318950a6d285e6dcc1844d8cdc0d140df)
Testing Done: of course none ;) Will update when I have some time to test
fupdown2's postinst and postrm scripts do not conform to Debian's policy
for maintainer scripts [1]. Specific non-conformance follows:
* fixed maintainer scripts so they only use /bin/sh as other shells are
non-essential packages and may not exist on the system
* fixed maintainer scripts so only actions specified by $1 are performed
per run of the script
* fixed maintainer scripts to only support specific values for $1, and
will otherwise exit with error
* included at the bottom of the postrm script the "#DEBHELPER#" tag as
during package building debianhelper will inject extra code at this
location
[1] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
(cherry picked from commit 2289fe4e90a0134fcb07fe7e2e838de755d73e68)
ifdown behaviour.
Testing Done: tested ifreload evo test case
ifreload_down_changed is 0 by default which will make
sure ifreload will not execute down on changed interfaces
but only on deleted interfaces making it non-disruptive.
some notes from CCR:
ifreload was designed to be an optimization for 'service networking
restart' or 'ifdown -a + ifup -a'.
essentially it is a combination of 'ifdown + ifup' with some smarts in
which interfaces it will execute ifdown on.
By default it does the below:
ifdown all interfaces that were deleted from the interfaces file
ifdown all interfaces that were changed from the last time they were
ifup'ed
ifup -a (execute ifup on all interfaces marked auto)
Did not realize people will use ifreload as much as they do today. Also,
they may execute it on a production box when changes are made. ifdown on a production box can be
disruptive because if the ifdown which is part of the ifreload.
To have a non-disruptive option to ifreload, 2.5 added a new option -c
that only executed 'ifup' on all interfaces. Thus reloading all auto +
any other interfaces that were once brought up on the box (essentially
all interfaces present in the saved state file). This by default did not
do anything to the interfaces that got deleted from the file. But had an
ifupdown2.conf toggle to do so.
Looking at the evo use case, they do want to use a single command that
modifies, adds, deletes with
minimum disruption. we can achieve maybe what they want with multiple
commands (But there is also a case of a bug in the build evo is running
which makes it not so easy ).
This patch fixes the bug and also tries to change the default ifreload
behaviour controllable via a variable in ifupdown2.conf.
when ifreload_down_changed=0 in ifupdown2.conf, ifreload will only
ifdown interfaces that were deleted
from the file but not the ones that changed. subsequent ifup as part of
ifreload on the interfaces
that changed will apply the delta. And ifreload_down_changed default
value is '0'.
WIth the patch, ifreload by default will do the below (going back to the
previous default is just a toggle in the ifupdown.conf file):
ifdown all interfaces that were deleted from the interfaces file
ifup -a (execute ifup on all interfaces marked auto)
It sounds like a big change of behaviour for a hotfix release, but
essentially the patch just moves a few things around. And the change in
behaviour is so subtle that it is not very visible.
It just makes it non-disruptive.
(cherry picked from commit 2f7977834d4912a69159d27e54ba201f58a321d8)
(cherry picked from commit 09f283009e7de62ef1d258de81c94cc86fa13323)
(cherry picked from commit 898562e0e2284ccdc201dafc62b25b928037e0c6)
Testing Done: Tested with shared slaves in bridge and bonds
(cherry picked from commit 6f990450001d367a775681a29cdce74f862f7848)
(cherry picked from commit 8d9a5107112628ee8434e227dff49a0ef09966ee)
Testing Done: tested ifreload with example in the bug
ifdown of the bridge svi was following the lowerdev and downing the
bridge. kernel implicitly deletes all svi's on bridge down.
ifup of the bridge usually handles it, but a change done in 2.5.1
was causing it not to. Thinking about this some more, its safe
to not follow dependents on down during a ifreload. This patch does
just that.
(cherry picked from commit 03f7a376aee944b4037b7b7b02a5096e9360f79e)
(cherry picked from commit aac5777ecc7d367ada0681f813fbec7f78fa80ee)
Testing Done: tested bridge and bonds with interfaces with configs
Both bridge and mstpctl modules set priv_flags on interfaces
that have configs (like link-speed) even when used as bridge-ports.
And this collision causes statemanager.ifaceobj_sync() to never get called
because ifaceobj.priv_flags is 1 (we return immediately):
The fix was to create a new iface module_flags array to carry module info.
(cherry picked from commit 56924fef20984fd959939bf7f17c3dd6fd6b137a)
(cherry picked from commit 28d96f7643e2885b1f9c17ad9324a6dbb1b0f8c7)
In addition fixed up the Debian maintainer scripts to prevent a
potential upgrade failure, discussion follows:
The Cause For the upgrade Failure
=================================
A commit introduced changes to
ifupdown2's package maintainer scripts to override some files provided
by the bridge-utils and udev packages as they conflict with ifupdown2.
The change to ifupdown2's postrm script is currently causing the script
to exit with a failure code if the following files do not exist on the
box:
/etc/udev/rules.d/80-networking.rules
/etc/udev/rules.d/60-bridge-network-interface.rules
The reason for this is in how the script is written.
Since the postrm script is configured to exit on the first command
failure, the "set -e" on line 3, the commands on lines 20 and 22 will
fail if the files being looked for do not exist, causing the script to
exit with a non-zero exit code. Causing apt to fail the upgrade.
.postrm script excerpt
----------
20 udevlink=$(readlink /etc/udev/rules.d/80-networking.rules 2>/dev/null)
21 [ -n "$udevlink" -a "$udevlink" == "/dev/null" ] && rm -f /etc/udev/rules.d/80-networking.rules
22 udevlink=$(readlink /etc/udev/rules.d/60-bridge-network-interface.rules 2>/dev/null)
23 [ -n "$udevlink" -a "$udevlink" == "/dev/null" ] && rm -f /etc/udev/rules.d/60-bridge-network-interface.rules
----------
Solution
--------
The solution requires having the newer version of the ifupdown2 package
provide a preinst script that gets run before the older package's postrm
script is run[1,2]. This gives us the opportunity to quietly fix the
problem. We also fix the postrm script in newer versions of the package
so it cannot bomb out in this way.
Finally, removed what appears to be a poor merge from commit
5f5d84e3261bf70dd3541666a3d3a7f817727ce6.
Fixes: 8959e8e4ec93487228733b17ef2b220ed47c1260
(cherry picked from commit 0eab79eb5aed4cdf0674e3f0ddad3631dd457bdc)
Conflicts:
packages/cl-utilities/debian/postinst
packages/cl-utilities/debian/prerm
Replaced vxlan-peernodeip attribute with vxlan-remoteip. Updated
the vxlan and iproute2 modules to configure head end replication
using bridge fdb commands.
(cherry picked from commit 567f445fc4a1828fc2aac0da3f2402a185656cb5)
Conflicts:
packages/ifupdown2/addons/vxlan.py
packages/ifupdown2/ifupdownaddons/iproute2.py
Conflicts:
ifupdown2/addons/vxlan.py
ifupdown2/ifupdownaddons/iproute2.py
MTU settings are defaulted 1500 when interface is ifdowned.
This has the effect of changing the MTU on the interface and any subinterfaces to
1500. And if these subinterfaces are in a bridge, the bridge will pick the MIN MTU
so the bridge keeps this MTU even after the interface is brought back up. The sub
interface does not change to a higher value then 1500 (kernel VLAN driver only
moves the MTU is the decreasing direction.
(cherry picked from commit 70e67ab15efb13e1499288152d801b39f28a190b)
(cherry picked from commit 56238543a980e983957a180c583b9412c3ab48ab)
Corrected a minor error in how we handle unsupported config attributes.
Instead of
error: not enough arguments for format string
we will now print this:
warning: peerlink.4000: unsupported attribute 'clagd-foobar'
(cherry picked from commit 44c6004a33d59ee234f8ee3d5f450e158c9e5bdc)
(cherry picked from commit f2c2321301d05e88d3c9ab9c26e6d4e256c884e9)
