git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[nova] Request to include routed networks support in the Ussuri cucly goals


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-networking-with-routed-networks).
> 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.html#network-aware-scheduling
>     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