Re: [openstack-dev] [Fuel] Plans on networking modularisation

[Aleksey Kasatkin]

Hi Ryan,

Thank you. We had a talk with Evgeniy. As a preliminary plan, we will have
meetings with all interested people from Networking team.

Regards,


Aleksey Kasatkin


On Tue, Mar 15, 2016 at 7:46 PM, Ryan Moe  wrote:

> Hi Aleksey,
>
>
>
>> 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]) ?
>>
>>
> AFAIK there are no other activities in progress right now.
>
>
>> 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.
>>
>
> You are correct. The intent was to end up with a separate network storage
> service and network manager as a client of this service (where appropriate).
>
>
>>
>> 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.
>>
>>
> I agree that moving network manager into an extension would be good. I
> think we'll need some discussion around that though. NetworkManager does a
> lot and some of it can be pushed off to a separate service but some will
> always be tied to Nailgun. I'm not sure how or if that will impact moving
> it into an extension.
>
>
>> 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 originally created a simple PoC (2.1) just to test out the idea. The
> Nailgun side of this work done since doesn't have any dependency on that
> PoC. We can freely change directions. Neutron handles a lot of what Nailgun
> cares about (networks, subnets, IP allocation, etc.) so I'm currently
> investigating it as an option.
>
>
>> I'd like to participate in design discussions. Please add me into
>> meetings.
>>
>
> I will make sure you're included. Your input would be greatly appreciated.
>
> Thanks,
> Ryan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Plans on networking modularisation

[Ryan Moe]

Hi Aleksey,



> 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]) ?
>
>
AFAIK there are no other activities in progress right now.


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

You are correct. The intent was to end up with a separate network storage
service and network manager as a client of this service (where appropriate).


>
> 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.
>
>
I agree that moving network manager into an extension would be good. I
think we'll need some discussion around that though. NetworkManager does a
lot and some of it can be pushed off to a separate service but some will
always be tied to Nailgun. I'm not sure how or if that will impact moving
it into an extension.


> 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 originally created a simple PoC (2.1) just to test out the idea. The
Nailgun side of this work done since doesn't have any dependency on that
PoC. We can freely change directions. Neutron handles a lot of what Nailgun
cares about (networks, subnets, IP allocation, etc.) so I'm currently
investigating it as an option.


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

I will make sure you're included. Your input would be greatly appreciated.

Thanks,
Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Plans on networking modularisation

[Aleksey Kasatkin]

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  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Plans on networking modularisation

[Evgeniy L]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev