This design doc adds details about how the autoconfiguration of
openvswitch should work in the cluster <-> node group <-> node
hierarchy. Parameters that are needed for succesful configration
are idenfied and inheritance of parameters is defined.
Also, some rephrasing of the definition in the first part of the
document. After looking into gnt-network, in my opinion it is not the
right place to put the switch management into, since it has more to
do with links and nics than with network names and addresses.
---
doc/design-openvswitch.rst | 35 +++++++++++++++++++++++++++++++----
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/doc/design-openvswitch.rst b/doc/design-openvswitch.rst
index e7ef686..555ad82 100644
--- a/doc/design-openvswitch.rst
+++ b/doc/design-openvswitch.rst
@@ -21,10 +21,10 @@ The shortcomings of this approach are:
Proposed changes
----------------
-1. Implement functions into gnt-network to manage Open vSwitch through Ganeti
gnt-network
- should be able to create, modify and delete vSwitches. The resulting
configuration shall
- automatically be done on all members of the node group. Connecting Ethernet
devices to
- vSwitches should be managed through this interface as well.
+1. Implement functions into gnt-cluster and gnt-node to manage Open vSwitch
through Ganeti.
+ It should be possible to create, modify and delete vSwitches. The resulting
configuration
+ shall automatically be done on all members of the node group, if possible.
Connecting Ethernet
+ devices to vSwitches should be managed through this interface as well.
2. Implement VLAN-capabilities: Instances shall have additional information
for every NIC: VLAN-ID
and port type. These are used to determine their type of connection to Open
vSwitch. This will
@@ -39,6 +39,29 @@ Proposed changes
bandwidth and maximum burst. This helps to balance the bandwidth needs
between the VMs and to
ensure fair sharing of the bandwidth.
+Automatic configuration of OpenvSwitches
+++++++++++++++++++++++++++++++++++++++++
+Ideally, the OpenvSwitch configuration should be done automatically.
+
+This needs to be done on node level, since each node can be individual and a
setting on cluster / node group
+level would be too global is thus not wanted.
+
+The task that each node needs to do is:
+ ``ovs-vsctl addbr <switchname>`` with <switchname> defaulting to
constants.DEFAULT_OVS
+ ``ovs-vsctl add-port <switchname> <ethernet device>`` optional: connection
to the outside
+
+This will give us 2 parameters, that are needed for the OpenvSwitch Setup:
+ switchname: Which will default to constants.DEFAULT_OVS when not given
+ ethernet device: Which will default to None when not given, might be more
than one (NIC bonding)
+
+These parameters should be set at node level for individuality, _but_ can have
defined defaults on cluster
+and node group level, which can be inherited and thus allow a cluster or node
group wide configuration.
+If a node is setup without parameters, it should use the settings from the
parent node group or cluster. If none
+are given there, defaults should be used.
+
+As a first step, this will be implemented for using 1 ethernet device only.
Functions for nic bonding will be added
+later on.
+
Configuration changes for VLANs
+++++++++++++++++++++++++++++++
nicparams shall be extended by a value "vlan" that will store the VLAN
information for each NIC.
@@ -71,6 +94,10 @@ Users of older Xen versions should be able to grab
vif-openvswitch from the Xen
gnt-instance modify shall be able to add or remove single VLANs from the vlan
string without users needing
to specify the complete new string.
+NIC bonding
++++++++++++
+To be done
+
Configuration changes for QoS
+++++++++++++++++++++++++++++
Instances shall be extended with configuration options for
--
1.8.1.2
