Open Stack

On Wed, Jul 01, 2015 at 10:26:43AM +0100, Bob Ball wrote:
> Hi Anthony,
> 
> > The Xen script is simply calling those commands:
> > ...
> >   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev"
> > -j ACCEPT
> >   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out
> > "$dev" -j ACCEPT
> 
> Are you saying that these two commands aren't needed to be called by Xen in the OpenStack case because, for example, forwarding is set up by nova-network?
> 
> > It is possible to have Nova asking to run a different script that would not
> > call iptables. But that script would need to be store somewhere, in the
> > nova repo would be best.
> 
> Did you mean for Xen to be calling the different script, rather than Nova?  If Nova is calling it then the obvious place is in the Nova repo.

What I meant is, when Nova is creating the XML guest config, it can set the
script parameter for the network interface.

> If it's a script that Xen needs to call then I would suggest it went to the contrib/xen directory.  There already appears to be a vif-script there which was implemented for Neutron, does that do what's needed here?

Thanks, I will look at this. Is this contrib/ dir going to be install
somewhere on a Nova release? So that there is no need for extra user
intervention at deployment time as long as Nova can generate an absolute
path for where the script is.

> > Is `iptables` call necessary for the vif with OpenStack?
> 
> Pass on that one - someone who knows libvirt might know if libvirt does everything that's needed in the Xen case or if there are kvm specific scripts.

I guest, the question is, is the default to ACCEPT everything or not.

> > If so, can nova-network do the update? Or the script called by the Xen
> > toolstack could take an OpenStack lock before calling iptables?
> 
> I'd hope that it's not necessary for the Xen script to invoke iptables; the idea of having the two processes working with the same lock for iptables sounds nasty (e.g. it might make it harder to know which process is holding on to the lock in the case of a bug).  If this really is needed perhaps Nova should be calling the iptables commands after setting up the VIF?  This way it's just Nova that's in control of the lock.

I think it's possible to have nova setting up the iptables for the vif,
we would just need nova to generate a name for the vif as it might be
difficult to guest the name of the interface.
(To guest, nova would need to know the domid, which libvirt should have.)

Thanks,

-- 
Anthony PERARD