Re: [openstack-dev] [Fuel] Plans on networking modularisation
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
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
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
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