Open Stack

Hi Andrey,

IMO the first choice (adding a new structure) is better because of the following reasons:

1.       The only source of truth for the networks allocations by the user can be the new roles_meta structure, while transformations can be changed in future versions or by plugins, according to a new OVS/LB design or structure.

2.       I’m not sure that inferring the physical interfaces allocation for network roles from transformations is correct, since the structure of transformations can be complicated (dictionary of dictionaries) and the bridge names can be manipulated.

3.       Since VLAN tags are being held by an ‘add-patch’ action dictionary in transformations, if some plugin / future design will add another ‘add-patch’ action dictionary to transformations, with the same bridge and with a different tag, then it will be hard to understand what was the original VLAN allocated to the desired bridge.

What do you think?

Thanks,
Aviram

From: Andrey Danin [mailto:adanin at mirantis.com]
Sent: Wednesday, February 25, 2015 10:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Fuel] [plugins] A simple network to interface mapping in astute.yaml

Hi, fuelers,
As you may know, we have a rich and complex network_transformations section in astute.yaml. We use it to describe which OVS/Linux network primitives should be created and how they should be connected together. This section is used by "l23network" Puppet module during the deployment stage.
The problem is that from plugin developer's stand point it's hard to parse a full transformation graph to find which interface/vlan is used for each network (Public, Private, etc.). I see two ways to fix that.
1) Add a new structure to astute.yaml with a simple mapping of networks to interfaces/vlans. Example: http://paste.openstack.org/show/181466/ (see roles_meta section).
Pros: it's very easy for plugin developers.
Cons: there are two sources of truth (roles_meta and transformations). If one plugin patch transformations but forget to patch roles_meta, another plugin, which relies on roles_meta, fails the deployment.
2) Provide a some kind of SDK - functions/libraries for Puppet/Python/Bash, which can be used in plugin's tasks to operate with graph of transformations.
Pros: single point of truth. One and controlled way to do things right.
Cons: a new piece of software will be issued. It must be written, tested, documented, and incorporated into CI/CD infrastructure.

I prefer the second way. Do you?

--
Andrey Danin
adanin at mirantis.com<mailto:adanin at mirantis.com>
skype: gcon.monolake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150226/148857f2/attachment.html>