<div dir="ltr"><div><div><div><div>Hi,<br><br></div><div>Evgeniy, thank you for summarizing this.<br></div><br></div><div>I have questions about action items.<br></div><div><br></div><div>What is the status of making networking part replaceable? As I know, [0] is in progress. Are there any other activities in progress (about API, serialization for orchestrator, network verification)? Do we have specs on review (I know about this one: [1]) ?<br></div><div><br>As I know, [0] is about separate storage service for networking related information (from what I've seen), not about moving all network-related code. Please correct me if it's not true.<br><br>AFAIC, [0] can be combined with moving of network part into extension (API, serialization). So, extension could use this storage. Network verification (net-checker) depends on networking data and it uses the same RPC so it can be more difficult to move its setup and results acquisition from Nailgun into extension.<br>I'm for networking as extension as it was done for "volume manager" already.<br><br></div>Please expand this a bit: "Reuse Neutron API with additional plugins/extensions to provide for us a way to also store bonds/nics related information."<br></div>As I understand, it's rather specific stuff and will cover very small part of the whole task. And as 2.1 is in progress already, 2.3 seems to be rejected..?<br><br></div><div>I'd like to participate in design discussions. Please add me into meetings.<br></div><div><br></div>Thanks,<br><div><div><div><br>[0] <a href="https://review.openstack.org/#/q/topic:bp/network-config-refactoring" target="_blank">https://review.openstack.org/#/q/topic:bp/network-config-refactoring</a><br>[1] <a href="https://review.openstack.org/#/c/290767/">https://review.openstack.org/#/c/290767/</a><br><br><br></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Mar 15, 2016 at 10:17 AM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@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">Hi,<div><br></div><div>We've been working on networking modularisation, during this activity Nailgun is being fixed [0] in order to provide better layer boundary between network related code and the rest of the system.</div><div><br></div><div>The purpose of this email is:</div><div>1. To make sure that this activity is known in Fuel team.</div><div>2. To make sure that we are on the same page.</div><div>3. To make sure that it's something valuable and most of the Fuel team supports it.</div><div><br></div><div>Some time ago I sent an email [1] on why we should do modularisation, here is this list:</div><div><div>1. Reusability of components.</div><div>1.1. It will lead to more components consumers (users).</div><div>1.2. Better integration with the community (some community projects may be interested in using some parts of Fuel and vice versa).</div><div>2. Components decoupling will lead to clear interfaces between components.</div><div>2.1. So it will be easier to replace some component.</div><div>2.2. It will be easier to split the work between teams and it will help to scale teams in a much more efficient way.</div></div><div><br></div><div>High level action items are:</div><div>1. Make networking part in Nailgun replaceable.</div><div>2. Make the replacement, currently evaluation of several options is in progress:</div><div>2.1. Implement separate service to store network related (ips/networks/bonds/nics) configuration. Code name is Illmatic.</div><div>2.2. Just make it as an extension.</div><div>2.3. Reuse Neutron API with additional plugins/extensions to provide for us a way to also store bonds/nics related information.</div><div><br></div><div>If you have any ideas or questions, don't hesitate to ask them.</div><div><br></div><div>Thanks,</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/q/topic:bp/network-config-refactoring" target="_blank">https://review.openstack.org/#/q/topic:bp/network-config-refactoring</a></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html</a></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>