<div dir="ltr">Hi Andrey,<div><br></div><div>I don't have enough details to make some conclusions, but if the</div><div>problem can be solved with some python script which gets the data</div><div>and converts it into more readable format, lets do it this way.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 10:59 PM, Andrey Danin <span dir="ltr"><<a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi, fuelers,<br><br></div>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.<br><br></div>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.<br><br></div>1) Add a new structure to astute.yaml with a simple mapping of networks to interfaces/vlans. Example: <a href="http://paste.openstack.org/show/181466/" target="_blank">http://paste.openstack.org/show/181466/</a> (see roles_meta section). <br>Pros: it's very easy for plugin developers. <br>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.<br><br></div>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. <br>Pros: single point of truth. One and controlled way to do things right.<br></div>Cons: a new piece of software will be issued. It must be written, tested, documented, and incorporated into CI/CD infrastructure.<br><br><br></div><div>I prefer the second way. Do you?<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><div><div><div><div><div><div><br>-- <br><div>Andrey Danin<br><a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a><br>skype: gcon.monolake<br></div>
</div></div></div></div></div></div></div></font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>