This patch proposes how to integrate QoS parameters into Ganeti. It is proposed to integrate them into the previously proposed link object, as this seems to be the most suitable solution. Other alternatives are discusse and their downsides shown.
Signed-off-by: Sebastian Gebhard <[email protected]> --- doc/design-openvswitch.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/doc/design-openvswitch.rst b/doc/design-openvswitch.rst index c003fe3..02fa946 100644 --- a/doc/design-openvswitch.rst +++ b/doc/design-openvswitch.rst @@ -134,6 +134,25 @@ Instances shall be extended with configuration options for - maximum bandwidth - maximum burst rate +These parameters should be setable *for each NIC of each instance*. Therefore +the ideal place for this parameter is in the above specified +nicparams[constants.NIC_LINK] dict, because this will stick to the NIC as well +as the instance. + +Other considered alternatives (and their downsides) are: +- with the OVS configuration / ndparams: + This is not desired, because it adds a huge overhead when instances are + migrated or failed over, since the OpenvSwitches are local to each node. + Information would need to be extracted, moved and reinserted or each + changes the the nodes of an instance. +- with the instance information: + This would solve migration issues, but still has downsides. QoS should be + usable for each NIC independently. Storing QoS parameters outside the NIC but + inside the instance will result in having to take care that the info will be + in sync the current NIC configuration. Each NIC operation (add / del ...) will + have to touch both objects. Therefore having QoS information inside nicparams + is the desirable way to go. + New configuration objects need to be created for the Open vSwitch configuration. All these configuration changes need to be made available on the whole node group. -- 1.8.1.2
