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. 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. 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. 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
signature.asc
Description: Digital signature
