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. 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? > 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. > 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. Bob __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
