Another thought that just came to my mind:
How would gnt-network cope with parameters that need to be set
individually for each instance?
VLAN is probably alright to be the same for all the NICs on the network,
but how about QoS params that one might want individually set for each
instance?
Cheers,
Sebastian
Am 18.09.2013 10:42, schrieb Sebastian Gebhard:
Hi Dimitris,
Am 16.09.2013 16:05, schrieb Dimitris Aragiorgis:
Hi,
* Sebastian Gebhard <[email protected]> [2013-09-13 12:27:28 +0000]:
Based on the previous proposed link object change, this patch changes
the the place where the vlan parameter is stored to the newly proposed
location inside the link dict.
Signed-off-by: Sebastian Gebhard <[email protected]>
---
doc/design-openvswitch.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/design-openvswitch.rst b/doc/design-openvswitch.rst
index 2474dd2..c003fe3 100644
--- a/doc/design-openvswitch.rst
+++ b/doc/design-openvswitch.rst
@@ -110,8 +110,9 @@ switch1.2:10:20 means that the VM is connected to a hybrid
port on switch1, carr
VLANs 10 and 20 tagged.
switch1:44:55 means that the VM is connected to a trunk port on switch1,
carrying VLANS 44 and 55
-This configuration string is split at the dot or colon respectively and stored in nicparams[constants.NIC_LINK]
-and nicparams[constants.NIC_VLAN] respectively. Dot or colon are stored as
well in nicparams[constants.NIC_VLAN].
+This configuration string is split at the dot or colon respectively and stored
in
+nicparams[constants.NIC_LINK]['interface'] and
nicparams[constants.NIC_LINK]['ovs']['vlan']
+respectively. Dot or colon are stored as well inside this dict item.
IMHO making `link` a dict is way too intrusive:
- instance related opcodes (gnt-instance add, modify)
- network related opcodes (gnt-network connect)
- VerifyConfig (nic tupples ensuring uniqueness)
- etc.
It breaks compatibility with older versions and needs a lot of refactoring.
Well, refactoring okay. But breaking compatibility is definitely bad. I
did overlook that.
I don't see any reason why not preserve link as a string and include all
the ovs info in a *strict* format (e.g switch1:44:55) for now, as we
discussed at the GanetiCon. When the ovs info grows a lot, maybe a *new
and optional* nicparam like the existing vlan can be added.
Okay, I guess I understood you wrong at GanetiCon. I thought by
extending 'link' you meant to change the type to hold more information
and not specify a format the string should have.
I would *not* prefer to refactor the code and squeeze VLAN info into
'link' now, as there will be further parameters coming up. So, in my
opinion, if we change it, we should change it properly. Not change it
now to squeeze everything into the string and then change it again once
the information is too much.
I would definitely vote for a new and optional nicparam.
But even if that happens, why not include this info (and the QoS related
one) in a L2 connected Network? netinfo is currently encapsulated in
each NIC object and is reachable at node level. I know the L2/L3 split
is not implemented yet but I wonder if this is the right way to go.
I have looked into the code of gnt-network now and I think it might be
okay. I am not completely sure how it will work exactly, but I trust you
on this.
What is the status of the L2/L3 split.
Also, do I see this correctly: This will *force* the user to specify
networks in order to use Open vSwitch, if I migrate everything into
gnt-network, right?
On the other hand: Once your L2/L3 split is through and everything is
implemented as shown in your presentation, everybody must specify
networks, because link and mode are set there, right?
What will be left over in the instance nicparams once this is finished?
Thanks,
Sebastian
Any thoughts?
dimara
For Xen hypervisors, this information can be concatenated again and stored in
the vif config as
the bridge parameter and will be fully compatible with vif-openvswitch as of
Xen 4.3.
--
1.8.1.2
