[nova] Request to include routed networks support in the Ussuri cucly goals
Hi Stackers, I want to request the inclusion of the support for Neutron Routed Networks in the Nova goals for the Ussuri cycle. As many of you might know, Routed networks is a feature in Neutron that enables the creation of very large virtual networks that avoids the performance penalties of large L2 broadcast domains ( https://www.openstack.org/videos/summits/barcelona-2016/scaling-up-openstack...). This functionality can be very helpful for large deployers who have the need to have one or a few large virtual networks shared by all their users and has been available in Neutron since very soon after the Barcelona Summit in 2016. But it is really useless until there is code in Nova that can schedule VMs to compute hosts based on the segments topology of the routed networks. Without it, VMs can land in compute hosts where their traffic cannot be routed by the underlying network infrastructure. I would like the Nova team to consider the following when making a decision about this request: 1. Work for Routed Networks was approved as a priority for the Ocata cycle, although it wasn't concluded: https://specs.openstack.org/openstack/nova-specs/priorities/ocata-priorities... and https://specs.openstack.org/openstack/nova-specs/specs/pike/index.html 2. The are several large deployers that need this feature. Verizon Media, my employer, is one of them. Others that come to mind include GoDaddy and Cern. And I am sure there are others. 3. There is a WIP patch to implement the functionality some of the functionality: https://review.opendev.org/#/c/656885. We, at Verizon Media, are proposing to take over this work and finish its implementation by the end of U. What we are requesting is Nova core reviewers bandwidth to help us merge the code I will be attending the PTG in Shanghai and will make myself available to discuss this further in person any day and any time. Hopefully, we can get this feature lined up very soon Best regards Miguel
On Mon, 2019-10-07 at 13:02 -0500, Miguel Lavalle wrote:
Hi Stackers,
I want to request the inclusion of the support for Neutron Routed Networks in the Nova goals for the Ussuri cycle. +1 As many of you might know, Routed networks is a feature in Neutron that enables the creation of very large virtual networks that avoids the performance penalties of large L2 broadcast domains ( https://www.openstack.org/videos/summits/barcelona-2016/scaling-up-openstack...). This functionality can be very helpful for large deployers who have the need to have one or a few large virtual networks shared by all their users and has been available in Neutron since very soon after the Barcelona Summit in 2016. But it is really useless until there is code in Nova that can schedule VMs to compute hosts based on the segments topology of the routed networks. Without it, VMs can land in compute hosts where their traffic cannot be routed by the underlying network infrastructure. I would like the Nova team to consider the following when making a decision about this request:
1. Work for Routed Networks was approved as a priority for the Ocata cycle, although it wasn't concluded: https://specs.openstack.org/openstack/nova-specs/priorities/ocata-priorities... and https://specs.openstack.org/openstack/nova-specs/specs/pike/index.html 2. The are several large deployers that need this feature. Verizon Media, my employer, is one of them. Others that come to mind include GoDaddy and Cern. And I am sure there are others. 3. There is a WIP patch to implement the functionality some of the functionality: https://review.opendev.org/#/c/656885. We, at Verizon Media, are proposing to take over this work and finish its implementation by the end of U. What we are requesting is Nova core reviewers bandwidth to help us merge the code
for context of other and to qualify for myself, the main work to "support this in nova" is related to the schduler and placement. if i remember correctly we prviosly discussed the idea of modeling the subnet/segment affinity between compute hosts and routed ip subents as placement aggreates that woudl be create by neutron. the available number of ips in each routed subnet would be modelled as an inventory of ips in a shareing resouce provider. during spawn when nova retrieves the port info from the precreated neturon port, neutron would pass a resources request for an ip and a aggreage using the existing resouce requests mechanism that was introduced for bandwith aware schduleing. nova then jsut need to merge the aggreage and ip requst with the other request form the port,flavor,image when it queries placment to ensure that the returned hosts are connected to the correct routed segment.
I will be attending the PTG in Shanghai and will make myself available to discuss this further in person any day and any time. Hopefully, we can get this feature lined up very soon i wont be at the PTG but i do think this i quite valuable as today the only way to use routed networks today is to ip_allocation=defer which means you cannot chose the ports ip ahead of time. also because we dont schduler based on compute host to segment affinity today it is not safe to live migrate,
cold migrate, resize or shelve instance with routed networks today as it coudl fail due to the segment being unreachable on the selected host. if we finish move operation for ports with resouce requests which we need for port with minium bandwith then it will fix all of the above for routed networks too.
Best regards
Miguel
On Mon, Oct 07, 2019 at 01:02:32PM -0500, Miguel Lavalle wrote:
Hi Stackers,
I want to request the inclusion of the support for Neutron Routed Networks in the Nova goals for the Ussuri cycle. As many of you might know, Routed networks is a feature in Neutron that enables the creation of very large virtual networks that avoids the performance penalties of large L2 broadcast domains ( https://www.openstack.org/videos/summits/barcelona-2016/scaling-up-openstack...). This functionality can be very helpful for large deployers who have the need to have one or a few large virtual networks shared by all their users and has been available in Neutron since very soon after the Barcelona Summit in 2016. But it is really useless until there is code in Nova that can schedule VMs to compute hosts based on the segments topology of the routed networks. Without it, VMs can land in compute hosts where their traffic cannot be routed by the underlying network infrastructure. I would like the Nova team to consider the following when making a decision about this request:
Is there a community-wide effort with this, or is this really just asking that Nova prioritize this work? The cycle goals (typically) have been used for things that we need the majority of the community to focus on in order to complete. If this is just something between Neutron and Nova, I don't think it really fits as a cycle goal. I do think it would be a good thing to try to complete in Ussuri though. Just maybe not as a community goal. Sean
On 10/7/2019 3:19 PM, Sean McGinnis wrote:
Is there a community-wide effort with this, or is this really just asking that Nova prioritize this work?
The cycle goals (typically) have been used for things that we need the majority of the community to focus on in order to complete. If this is just something between Neutron and Nova, I don't think it really fits as a cycle goal.
I do think it would be a good thing to try to complete in Ussuri though. Just maybe not as a community goal.
Miguel isn't talking about cycle wide goals. There are some proposed process changes for nova in Ussuri [1] along with constraining the amount of feature work approved for the release. I think Miguel is just asking that routed networks support is included in that bucket and I'm sure the answer is, like for anything, "it depends". From a wider governance perspective, if people interested in developing this feature were looking for an officially blessed thing, this would be a pop-up team. [1] https://review.opendev.org/#/c/685857/ -- Thanks, Matt
Miguel isn't talking about cycle wide goals. There are some proposed process changes for nova in Ussuri [1] along with constraining the amount of feature work approved for the release. I think Miguel is just asking that routed networks support is included in that bucket and I'm sure the answer is, like for anything, "it depends".
Agreed. What hasn't changed is that to get to the table it will need a blueprint [1] (which I don't see yet [2]) and spec [3] (likewise [4]). efried [1] https://blueprints.launchpad.net/nova/ussuri/+addspec [2] https://blueprints.launchpad.net/nova/ussuri [3] http://specs.openstack.org/openstack/nova-specs/readme.html [4] https://review.opendev.org/#/q/project:openstack/nova-specs+status:open
Miguel isn't talking about cycle wide goals. There are some proposed process changes for nova in Ussuri [1] along with constraining the amount of feature work approved for the release. I think Miguel is just asking that routed networks support is included in that bucket and I'm sure the answer is, like for anything, "it depends".
Agreed. What hasn't changed is that to get to the table it will need a blueprint [1] (which I don't see yet [2]) and spec [3] (likewise [4]). for this specific effort while it would not be a community wide goal this effort might benefit form a pop-up team of nova, placement and neutron developers to Shepard it along. i have to admit while we discussed this at some length at the PTG i did not follow
On Mon, 2019-10-07 at 17:28 -0500, Eric Fried wrote: the neutron development to see if they had got to the point of modelling subnets/segments as placement aggregates and sharing resource providers of ips. we have definitely made progress on the nova side thanks to gibi on move operations for ports with resource requests. having a fourm to bring the 3 project together may help finally get this over the line. that said i am not sure what remains to be done on the neutron side and what nova needs to do. I speculated about the gaps in my previous responce based on the desgin we discussed in the past. The current WIP patch was uploaded by matt https://review.opendev.org/#/c/656885 so i think he understands nova process better then most, that said if migule and matt are tied up with things i can try and help with the paperwork. Matt you have not been active on that patch since may is this something you have time/intend to work on for Ussuri? im not necessarily signing up to work on this at this point but it is a feature i think we should add and given i have not finalise what work i intent to do in U i might be able to help. @matt one point on your last comment to that patch that does perplex me somewhat was the assertion/implication configuration of nova host aggreates woudl be required. part of the goal as i understood it was to require no configuration on the nova side at all. i.e. instead of haveing a config option for a prefilter to update the request spec by transforming the subnets into placement aggreates we would build on the port requests feature we used for bandwith based schduling so that neutron can provide a resouce request for an ip and aggreate per port. we could discuss this in a spec but the reason i bring it up is the current patch looks like it would be problematic if you have a cloud with multiple network backeds say sriov and calico as its a global config rather then a backend specific behavior that builds on the generic perport resource requests. anyway that is an implemantion detail/design choice that we can discuss else where i just wanted to point it out.
efried
[1] https://blueprints.launchpad.net/nova/ussuri/+addspec [2] https://blueprints.launchpad.net/nova/ussuri [3] http://specs.openstack.org/openstack/nova-specs/readme.html [4] https://review.opendev.org/#/q/project:openstack/nova-specs+status:open
participants (5)
-
Eric Fried
-
Matt Riedemann
-
Miguel Lavalle
-
Sean McGinnis
-
Sean Mooney