Roopa Prabhu [Mon, 6 Oct 2014 18:11:10 +0000 (11:11 -0700)]
support for new bridge driver syntax
Ticket: CM-3346
Reviewed By:
Testing Done: tested vmware interfaces file with old and new formats
details:
- move bridge port membership to under the port
- move bridge port attributes under ports
- bridge attributes continue to remain under bridge
- special vlan interface for vlan attributes and svi config (iface
vlan-<vlanid/range>)
- maintain backward compatibility with all previously released bridge
config formats for vlan aware bridge
Open issues:
- check and running support will be done part of CM-3784
- ifquery currently expands and prints all the vlan-* interfaces.
Ticket:
Reviewed By:
Testing Done: Tested with old and new bridge driver
Examples:
old bridge driver:
%for v in range(100, 104):
auto br${v}
iface br${v}
bridge-ports uplink1.${v} peerlink.${v} downlink.${v} glob
swp2-4.${v}
bridge-stp on
svi-router-ip 11.${v/256}.${v%256}.240/24
svi-router-mac 00:00:5e:00:01:00
svi-router-virtual-ip 11.${v/256}.${v%256}.241/24
svi-router-virtual-mac 00:11:22:33:44:00
%endfor
new bridge driver:
%for v in range(100, 101):
auto br0.${v}
iface br0.${v}
svi-router-ip 11.${v/256}.${v%256}.240/24
svi-router-mac 00:00:5e:00:01:00
svi-router-virtual-ip 11.${v/256}.${v%256}.241/24
svi-router-virtual-mac 00:11:22:33:44:00
%endfor
Pending issues:
- optimization (its slow with 2000 svi's today)
- ifquery check and running support
- names of attributes and macvlan interfaces may change after review
Ticket: CM-3208
Reviewed By:
Testing Done: Tested with testcase listed in the bug
This patch does the following:
- moves the interface error exit check to before upperifaces are brought
up
- changes errors to warns on upperiface error (this is because
upperiface 'up' is done as best effort to reconfigure the interface in
question as slave device to the upper device. But if the upper device
is not in a right state config steps can fail. And we should just
warn).
- Implicitly bringing up the upperifaces helps in most of the cases. especially
when a bond is brought down and up. The upperiface handling code adds
the bond back into bridges it was part of. or creates the vlan devices
on the bond that got deleted. But there can be cases where upperifaces are
not in the right state and this results in warnings.
To disable the implicit upperiface handling, this patch also supports
'skip_upperifaces=1' in /etc/network/ifupdown2/ifupdown2.conf
in future, i am thinking of an option --skip-upperifaces to ifup
Bump kernel ethtool get/set wait to 20 + ifupdown2 convert ethtool
errors to warns
Ticket: CM-3159
Reviewed By: briefly ran this by jtoppins and andy (sfeldma is on
vacation this week).
Testing Done: tested ifupdown2 with ethtool config during boot (sam will
also be adding the testcase mentioned in the bug to ifupdown2 smoke)
The kernel timeout increase helps right now.
we should revisit this again in 2.3 to close all corner cases.
ifupdown2 will now warn on ethtool errors and will also return
non-zero exit status
Roopa Prabhu [Fri, 13 Jun 2014 13:08:40 +0000 (06:08 -0700)]
Fix upperiface check when ifdown is run with -a
Ticket: CM-3007
Reviewed By: shm + patch was pasted in the bug for review
Testing Done: ran precommit + maliks test + malik ran his test on his
box
When -a is specified ifupdown2 works on all interfaces and since the the
upperiface check is a bit expensive i had a "skip" on that.
And so far all the user commands i have seen only work on the $IFACE and
not its dependents. So, never hit this case.
Ticket: CM-3208
Reviewed By:
Testing Done: Tested with testcase listed in the bug
This patch does the following:
- moves the interface error exit check to before upperifaces are brought
up
- changes errors to warns on upperiface error (this is because
upperiface 'up' is done as best effort to reconfigure the interface in
question as slave device to the upper device. But if the upper device
is not in a right state config steps can fail. And we should just
warn).
- Implicitly bringing up the upperifaces helps in most of the cases. especially
when a bond is brought down and up. The upperiface handling code adds
the bond back into bridges it was part of. or creates the vlan devices
on the bond that got deleted. But there can be cases where upperifaces are
not in the right state and this results in warnings.
To disable the implicit upperiface handling, this patch also supports
'skip_upperifaces=1' in /etc/network/ifupdown2/ifupdown2.conf
in future, i am thinking of an option --skip-upperifaces to ifup
Bump kernel ethtool get/set wait to 20 + ifupdown2 convert ethtool
errors to warns
Ticket: CM-3159
Reviewed By: briefly ran this by jtoppins and andy (sfeldma is on
vacation this week).
Testing Done: tested ifupdown2 with ethtool config during boot (sam will
also be adding the testcase mentioned in the bug to ifupdown2 smoke)
The kernel timeout increase helps right now.
we should revisit this again in 2.3 to close all corner cases.
ifupdown2 will now warn on ethtool errors and will also return
non-zero exit status
Ticket: CM-3208
Reviewed By:
Testing Done: Tested with testcase listed in the bug
This patch does the following:
- moves the interface error exit check to before upperifaces are brought
up
- changes errors to warns on upperiface error (this is because
upperiface 'up' is done as best effort to reconfigure the interface in
question as slave device to the upper device. But if the upper device
is not in a right state config steps can fail. And we should just
warn).
- Implicitly bringing up the upperifaces helps in most of the cases. especially
when a bond is brought down and up. The upperiface handling code adds
the bond back into bridges it was part of. or creates the vlan devices
on the bond that got deleted. But there can be cases where upperifaces are
not in the right state and this results in warnings.
To disable the implicit upperiface handling, this patch also supports
'skip_upperifaces=1' in /etc/network/ifupdown2/ifupdown2.conf
in future, i am thinking of an option --skip-upperifaces to ifup
Bump kernel ethtool get/set wait to 20 + ifupdown2 convert ethtool
errors to warns
Ticket: CM-3159
Reviewed By: briefly ran this by jtoppins and andy (sfeldma is on
vacation this week).
Testing Done: tested ifupdown2 with ethtool config during boot (sam will
also be adding the testcase mentioned in the bug to ifupdown2 smoke)
The kernel timeout increase helps right now.
we should revisit this again in 2.3 to close all corner cases.
ifupdown2 will now warn on ethtool errors and will also return
non-zero exit status
Roopa Prabhu [Fri, 13 Jun 2014 13:08:40 +0000 (06:08 -0700)]
Fix upperiface check when ifdown is run with -a
Ticket: CM-3007
Reviewed By: shm + patch was pasted in the bug for review
Testing Done: ran precommit + maliks test + malik ran his test on his
box
When -a is specified ifupdown2 works on all interfaces and since the the
upperiface check is a bit expensive i had a "skip" on that.
And so far all the user commands i have seen only work on the $IFACE and
not its dependents. So, never hit this case.
Roopa Prabhu [Fri, 13 Jun 2014 13:08:40 +0000 (06:08 -0700)]
Fix upperiface check when ifdown is run with -a
Ticket: CM-3007
Reviewed By: shm + patch was pasted in the bug for review
Testing Done: ran precommit + maliks test + malik ran his test on his
box
When -a is specified ifupdown2 works on all interfaces and since the the
upperiface check is a bit expensive i had a "skip" on that.
And so far all the user commands i have seen only work on the $IFACE and
not its dependents. So, never hit this case.
The python argcomplete module that i use for ifupdown2 has a limitation
that it does not work with sudo when used in the global mode. But there is
a workaround for it online (long story short...instead of enabling the global
argparse complete ...the author recommends registering argparse complete bash
completion individually for your script). This patch does just that.
This patch also moves the udev overrides to their respective packages.
Two of them are owned by ifupdown2.
The python argcomplete module that i use for ifupdown2 has a limitation
that it does not work with sudo when used in the global mode. But there is
a workaround for it online (long story short...instead of enabling the global
argparse complete ...the author recommends registering argparse complete bash
completion individually for your script). This patch does just that.
This patch also moves the udev overrides to their respective packages.
Two of them are owned by ifupdown2.
Roopa Prabhu [Sun, 1 Jun 2014 18:12:06 +0000 (11:12 -0700)]
Use closefds=True and shell=True when executing usercmds
Ticket: CM-1438
Reviewed By: reported by purna
Testing Done: Tested with purna's l2 l3 lag test
problem fixed by this patch:
In some cases the child processes executing user cmds seem to hold on to
the lock file fd for a lil longer, preventing another instance of
ifupdown from running immediately after. Seen with two immediate
instances of service networking restarts from scripts when the
interfaces file has many user cmds.
Roopa Prabhu [Sun, 1 Jun 2014 18:12:06 +0000 (11:12 -0700)]
Use closefds=True and shell=True when executing usercmds
Ticket: CM-1438
Reviewed By: reported by purna
Testing Done: Tested with purna's l2 l3 lag test
problem fixed by this patch:
In some cases the child processes executing user cmds seem to hold on to
the lock file fd for a lil longer, preventing another instance of
ifupdown from running immediately after. Seen with two immediate
instances of service networking restarts from scripts when the
interfaces file has many user cmds.
roopa [Mon, 26 May 2014 16:03:29 +0000 (09:03 -0700)]
Fix bug during handling multiple iface sections for same interface
Ticket: CM-1438
Reviewed By:
Testing Done: Tested ifupdown2 sanity + multiple iface sections for an
interface
- This patch fixes a few shortcomings in the multiple iface sections
for same interface (partly because i was only covering
backward compatibility cases earlier)
- Since this is a very common configuration pattern, this patch cleans
it up
- also restructures some code
- main change is:
before:
for iface in ifaces:
for op in ops:
run op on iface
after:
for op in ops:
for iface in ifaces:
run op on iface
roopa [Mon, 26 May 2014 16:03:29 +0000 (09:03 -0700)]
Fix bug during handling multiple iface sections for same interface
Ticket: CM-1438
Reviewed By:
Testing Done: Tested ifupdown2 sanity + multiple iface sections for an
interface
- This patch fixes a few shortcomings in the multiple iface sections
for same interface (partly because i was only covering
backward compatibility cases earlier)
- Since this is a very common configuration pattern, this patch cleans
it up
- also restructures some code
- main change is:
before:
for iface in ifaces:
for op in ops:
run op on iface
after:
for op in ops:
for iface in ifaces:
run op on iface
This also pulls in python-gvgen package from wheezy sid into our
upstream dir. Previously i had packaged the gvgen module directly
into the ifupdown package
This also pulls in python-gvgen package from wheezy sid into our
upstream dir. Previously i had packaged the gvgen module directly
into the ifupdown package
dpkg-configure during build seems to be picking up python2.6 and
python2.6 was complaining about the syntax. Fixed with syntax
compatible with python2.6
Fixes to some corner cases + support for some missing 'options and
attributes' for backward compatibility
Ticket: CM-1438
Reviewed By:
Testing Done: Tested ifupdown sanity and new functionality
support for:
- -i <interface file>
- template lookup path and move all template handling to a separate
module template.py
- new ifupdown2 config file /etc/network/ifupdown2/ifupdown2.conf
- bridge_waitport and bridge_maxwait
- moved addons.conf to /var/lib/ifupdownaddons/
Old ifupdown allowed multiple stanza's for the same interface.
To support older files ifupdown2 will continue to support duplicate interfaces.
However this check will warn on interfaces with same config more than
once. The check is done at a higher level during parsing and hence only
does a string compare of the iface section.
projects / mirror_ifupdown2.git / log