[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] hotplug/Linux: Add --wait to iptables calls.



On Mon, Jun 01, 2015 at 05:09:56PM +0100, Anthony PERARD wrote:
> On Mon, Jun 01, 2015 at 04:17:51PM +0100, Ian Campbell wrote:
> > On Mon, 2015-06-01 at 16:08 +0100, Jan Beulich wrote:
> > > >>> On 01.06.15 at 16:59, <anthony.perard@xxxxxxxxxx> wrote:
> > > > --- a/tools/hotplug/Linux/vif-common.sh
> > > > +++ b/tools/hotplug/Linux/vif-common.sh
> > > > @@ -130,9 +130,9 @@ frob_iptable()
> > > >      local c="-D"
> > > >    fi
> > > >  
> > > > -  iptables "$c" FORWARD -m physdev --physdev-is-bridged --physdev-in 
> > > > "$dev" \
> > > > +  iptables --wait "$c" FORWARD -m physdev --physdev-is-bridged 
> > > > --physdev-in "$dev" \
> > > >      "$@" -j ACCEPT 2>/dev/null &&
> > > > -  iptables "$c" FORWARD -m physdev --physdev-is-bridged --physdev-out 
> > > > "$dev" \
> > > > +  iptables --wait "$c" FORWARD -m physdev --physdev-is-bridged 
> > > > --physdev-out "$dev" \
> > > >      -j ACCEPT 2>/dev/null
> > > >  
> > > >    if [ \( "$command" == "online" -o "$command" == "add" \) -a $? -ne 0 
> > > > ]
> > > 
> > > Looking at my oldest system's "iptables --help" I can't spot such an
> > > option (which doesn't necessarily mean it's not supported). Did you
> > > make sure all (older) distros we care about actually support this?
> 
> --wait does not appear work on a debian weezy (Debian 7.8).
> 
> > It's not really clear if/why --wait is the solution to the problem of
> > another party using iptables-{save,restore} to do their own network
> > management in the first place.
> > 
> > If OpenStack is doing save/modify/restore then what stops us rewriting
> > things in the middle and then getting those changes clobbered on
> > restore? Surely iptables-save can't exit holding the lock...
> 
> That could be an issue.
> 
> > And if nova-network is managing networking do we really need to do it
> > too?
> 
> I will investigate in that, check what there are doing, and what we are
> doing. The solution might just be a script=none.
> 

This makes sense. If OpenStack wants to be in charge of network topology
libxl probably don't want to mess with that.

There is a field called script in libxl_device_nic, in case you're
wondering how to pass that information to libxl.

Wei.

> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.