A script to use with OpenStack instead of vif-bridge
RFC PATCH 1/1 A script to use with OpenStack instead of vif-bridge
Hi,
I have submitted a script to be used by OpenStack instead of our vif-bridge
script: https://review.openstack.org/201257/
This is because vif-bridge is calling iptables and OpenStack (nova-network) is also updating the iptables (via iptables-{save,restore}).
Could you review this patch that I have append bellow?
Also, would it be better to have a similair script in Xen repo instead of Nova?
The script is based on another already present in nova:
http://git.openstack.org/cgit/openstack/nova/tree/contrib/xen/vif-openstack
Thanks.
The patch:
Quoted 1 line
From
cb7daaab757f5f744dc9c3698e67b451db3392feMon Sep 17 00:00:00 2001
From: Anthony PERARD <[email protected]>
Date: Mon, 13 Jul 2015 16:39:25 +0100
Subject: [PATCH] contrib: Add vif-bridge-nova-network script for Xen.
This script adds a vif created for a Xen guest to the bridge. This script is to be called by the Xen toolstack instead of the default one as the default will make call to iptables in a way that is not compatible with nova uses of iptables.
To make use of the script, it is to be placed in XEN_SCRIPT_DIR (likely to be /etc/xen/scripts) and adds the following in nova.conf:
[libvirt]xen_vif_bridge_script_path = vif-bridge-nova-network
Change-Id: Ief24f0eff85f9b5a5f8cf26c3e08c4d8aeabc789
Partial-Bug: #1461642
--- contrib/xen/vif-bridge-nova-network | 47 +++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100755 contrib/xen/vif-bridge-nova-network
contrib/xen/vif-bridge-nova-network new file +47 -0
@@ -0,0 +1,47 @@ +#!/bin/bash +# copyright: B1 Systems GmbH <[email protected]>, 2012. +# author: Christian Berendt <[email protected]>, 2012. +# Copyright (C) 2015, Citrix Ltd. +# +# Licensed under the Apache License, Version 2.0 (the "License"); you may +# not use this file except in compliance with the License. You may obtain +# a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT +# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the +# License for the specific language governing permissions and limitations +# under the License. +# +# Use this script instead of the default one to avoid iptables call from +# the script which may conflict with Nova use of iptables. +# +# usage: +# place the script in $XEN_SCRIPT_DIR (likely to be /etc/xen/scripts) +# and set the following in /etc/nova/nova.conf: +# [libvirt] +# xen_vif_bridge_script_path = vif-bridge-nova-network + +dir=$(dirname "$0") +. "$dir/vif-common.sh" + +bridge=$(xenstore_read_default "$XENBUS_PATH/bridge" "$bridge") + +case "$command" in + add|online) + setup_virtual_bridge_port "$dev" + add_to_bridge "$bridge" "$dev" + ;; + + remove|offline) + do_without_error brctl delif "$bridge" "$dev" + do_without_error ip link set $dev down + ;; +esac + +if [ "$type_if" = vif -a "$command" = "online" ] +then + success +fi
Signature · 1 line
Anthony PERARD
Quoted 11 lines · Anthony PERARD
Hi,
I have submitted a script to be used by OpenStack instead of our vif-bridge
script: https://review.openstack.org/201257/
This is because vif-bridge is calling iptables and OpenStack (nova-network) is also updating the iptables (via iptables-{save,restore}).Could you review this patch that I have append bellow?
Also, would it be better to have a similair script in Xen repo instead of Nova?
I think either would be fine, I don't currently know of any out of tree vif-* scripts but there are a few block-* ones and I don't see why vif-* should be treated differently e.g. from a compatibility PoV so out of tree is fine.
[...]
contrib/xen/vif-bridge-nova-network line 25
Quoted 5 lines
contrib/xen/vif-bridge-nova-network new file +5
-0+# usage: +# place the script in $XEN_SCRIPT_DIR (likely to be /etc/xen/scripts) +# and set the following in /etc/nova/nova.conf: +# [libvirt] +# xen_vif_bridge_script_path = vif-bridge-nova-network
Would it be possible/sensible to cause this to be the default if $somethingelse was set for Xen generally?
contrib/xen/vif-bridge-nova-network line 34
Quoted 9 lines
contrib/xen/vif-bridge-nova-network new file +9
-0+ +dir=$(dirname "$0") +. "$dir/vif-common.sh" + +bridge=$(xenstore_read_default "$XENBUS_PATH/bridge" "$bridge") + +case "$command" in + add|online) + setup_virtual_bridge_port "$dev"
Do you want/need
set_mtu $bridge $dev
here?
contrib/xen/vif-bridge-nova-network line 42
Quoted 8 lines
contrib/xen/vif-bridge-nova-network new file +8
-0+ add_to_bridge "$bridge" "$dev" + ;; + + remove|offline) + do_without_error brctl delif "$bridge" "$dev" + do_without_error ip link set $dev down + ;; +esac
You've omitted the various call_hooks, which means they won't work under Nova, I don't know if they are useful in that context, but I imagine they might be.
Quoted 6 lines
contrib/xen/vif-bridge-nova-network new file +5
-0+ +if [ "$type_if" = vif -a "$command" = "online" ] +then + success +fi
Quoted 10 lines · Ian Campbell
Quoted 9 lines · Anthony PERARD
Hi,
I have submitted a script to be used by OpenStack instead of our vif-bridge
script: https://review.openstack.org/201257/
This is because vif-bridge is calling iptables and OpenStack (nova-network) is also updating the iptables (via iptables-{save,restore}).Could you review this patch that I have append bellow?
Quoted 7 lines
Quoted 2 lines
Also, would it be better to have a similair script in Xen repo instead of Nova?
I think either would be fine, I don't currently know of any out of tree vif-* scripts but there are a few block-* ones and I don't see why vif-* should be treated differently e.g. from a compatibility PoV so out of tree is fine.
There is at least one vif-* in Nova.
Quoted 9 lines
[...]
contrib/xen/vif-bridge-nova-network line 25
Quoted 5 lines
contrib/xen/vif-bridge-nova-network new file +5
-0+# usage: +# place the script in $XEN_SCRIPT_DIR (likely to be /etc/xen/scripts) +# and set the following in /etc/nova/nova.conf: +# [libvirt] +# xen_vif_bridge_script_path = vif-bridge-nova-networkWould it be possible/sensible to cause this to be the default if $somethingelse was set for Xen generally?
If this was to be the default, then that will break Xen guest creation under OpenStack if the script is not there.
But I intend to write this in the documentation and try to have devstack do the setup as well.
Beyond that, it would be for the package to set things up properly. I've seen a specific nova-libvirt-xen package in ubuntu that already set libvirt.virt_type=xen in nova.conf.
Quoted 5 lines
Quoted 5 lines
contrib/xen/vif-bridge-nova-network new file +5
-0+ +dir=$(dirname "$0") +. "$dir/vif-common.sh" + +bridge=$(xenstore_read_default "$XENBUS_PATH/bridge" "$bridge")
Quoted 8 lines
contrib/xen/vif-bridge-nova-network line 34
Quoted 4 lines
contrib/xen/vif-bridge-nova-network new file +4
-0+ +case "$command" in + add|online) + setup_virtual_bridge_port "$dev"Do you want/need
set_mtu$bridge $dev
here?
I'll add it.
Quoted 4 lines
Quoted 4 lines
contrib/xen/vif-bridge-nova-network new file +4
-0+ add_to_bridge "$bridge" "$dev" + ;; + + remove|offline)
Quoted 8 lines
contrib/xen/vif-bridge-nova-network line 42
Quoted 4 lines
contrib/xen/vif-bridge-nova-network new file +4
-0+ do_without_error brctl delif "$bridge" "$dev" + do_without_error ip link set $dev down + ;; +esacYou've omitted the various
call_hooks, which means they won't work under Nova, I don't know if they are useful in that context, but I imagine they might be.
Ok, I'll add the call_hooks.
Thanks,
Signature · 1 line
Anthony PERARD
Quoted 11 lines · Anthony PERARD
Quoted 8 lines
contrib/xen/vif-bridge-nova-network line 25
Quoted 5 lines
contrib/xen/vif-bridge-nova-network new file +5
-0+# usage: +# place the script in $XEN_SCRIPT_DIR (likely to be /etc/xen/scripts) +# and set the following in /etc/nova/nova.conf: +# [libvirt] +# xen_vif_bridge_script_path = vif-bridge-nova-networkWould it be possible/sensible to cause this to be the default if $somethingelse was set for Xen generally?
If this was to be the default, then that will break Xen guest creation under OpenStack if the script is not there.
Oh, I assumed this would come as part of OpenStack somehow, but if that's not how it is structured then fine ;-)