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

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

[Anthony PERARD]

This help to avoid guest creation error when a downstream project is also
updating the iptables at guest creation time.

The error seen is this one:
  libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
  /etc/xen/scripts/vif-bridge online [-1] exited with error status 4

Apparently, exit status 4 could be a try again error.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---

This error is seen while using OpenStack with nova-network service running
(instead of Neutron). OpenStack is updating the iptables with iptables-save
and iptables-restore.

The status 4 error also happend at guest shutdown time (with vif-bridge
offline ...) and it appear to happen more often, but that not an issue
since the guest is been destroy.

Host: Ubuntu 14.04 (which have Xen 4.4)
---
 tools/hotplug/Linux/vif-common.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hotplug/Linux/vif-common.sh b/tools/hotplug/Linux/vif-common.sh
index fa0a18e..5780343 100644
--- 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 ]
-- 
Anthony PERARD

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

[Jan Beulich]

>>> On 01.06.15 at 16:59, <anthony.perard@citrix.com> 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?

Jan

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

[Ian Campbell]

On Mon, 2015-06-01 at 16:08 +0100, Jan Beulich wrote:
> >>> On 01.06.15 at 16:59, <anthony.perard@citrix.com> 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?

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...

And if nova-network is managing networking do we really need to do it
too?

Ian.

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

[Anthony PERARD]

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@citrix.com> 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.

-- 
Anthony PERARD

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

[Wei Liu]

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@citrix.com> 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

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

[Ian Campbell]

On Mon, 2015-06-01 at 17:09 +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@citrix.com> 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.

Or script=nova-network even.

Ian.