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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to