Open Stack

Hi,

Evgeniy, thank you for summarizing this.

I have questions about action items.

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]) ?

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.

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.
I'm for networking as extension as it was done for "volume manager" already.

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."
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..?

I'd like to participate in design discussions. Please add me into meetings.

Thanks,

[0] https://review.openstack.org/#/q/topic:bp/network-config-refactoring
[1] https://review.openstack.org/#/c/290767/



Aleksey Kasatkin


On Tue, Mar 15, 2016 at 10:17 AM, Evgeniy L <eli at mirantis.com> wrote:

> Hi,
>
> 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.
>
> The purpose of this email is:
> 1. To make sure that this activity is known in Fuel team.
> 2. To make sure that we are on the same page.
> 3. To make sure that it's something valuable and most of the Fuel team
> supports it.
>
> Some time ago I sent an email [1] on why we should do modularisation, here
> is this list:
> 1. Reusability of components.
> 1.1. It will lead to more components consumers (users).
> 1.2. Better integration with the community (some community projects may be
> interested in using some parts of Fuel and vice versa).
> 2. Components decoupling will lead to clear interfaces between components.
> 2.1. So it will be easier to replace some component.
> 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.
>
> High level action items are:
> 1. Make networking part in Nailgun replaceable.
> 2. Make the replacement, currently evaluation of several options is in
> progress:
> 2.1. Implement separate service to store network related
> (ips/networks/bonds/nics) configuration. Code name is Illmatic.
> 2.2. Just make it as an extension.
> 2.3. Reuse Neutron API with additional plugins/extensions to provide for
> us a way to also store bonds/nics related information.
>
> If you have any ideas or questions, don't hesitate to ask them.
>
> Thanks,
>
> [0] https://review.openstack.org/#/q/topic:bp/network-config-refactoring
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160315/4cd72caa/attachment.html>