[nova][neutron] nova scheduling support for routed networks
melwittt at gmail.com
Wed Feb 26 18:56:51 UTC 2020
On 2/26/20 04:06, Balázs Gibizer wrote:
> There are multiple efforts to add scheduler support to the neutron
> routed network feature.
> Matt's effort to have it as a scheduler pre-filter 
> Adam's (rm_work) effort to have this as a a new scheduler hint and a
> new scheduler filter 
> We had a good discussion on #openstack-nova  about the possible way
> forward with Sean and Adam. Here is a summary and my proposed way
> Currently booting a server in a routed network setup works iff the
> neutron port is pre-created with ip_allocation=deferred before the
> server create. Nova then schedule the server without consider anything
> about the possible multiple network segments of the port. Neutron will
> do the segment assignment when the port is bond to the compute host.
> The problem is that once a port bound to a segment it cannot be bound
> to another segment as that would change the IP of the port. So if a
> server is migrated nova should select a destination host where the
> _same segment_ is available. Therefore we need a way to influence the
> scheduling based on the assigned segment id of the port. Both  and
>  does that based on the fact that neutron creates nova host
> aggregates for each network segment and those aggregates are mirrored
> to placement as placement aggregates.
> For me the pre-filter approach seems better as
> * it avoids introducing a new scheduler hint
> * it is not affected by the allocation candidate limit configuration
> that effect scheduler filters
> * it allows us to iterate towards an approach where neutron provides
> the required aggregates of each port via the ports' resource_request
> The downside of the pre-filter approach is that right now it needs to
> query the segments for each network / port the server has before the
> each scheduling. I think we limit such performance impact by making
> this pre-filter turned off by default via configuration. So a
> deployment without routed networks does not need to pay this cost.
> Later this cost can be nullified by extending neutron to specify the
> needed aggregates in the port's resource_request.
> I'm now planning to take  over from Matt and finish it up by adding
> functional test and documentation to it.
> I would also like to raise attention to the tempest patch that adds
> basic CI coverage for the currently working server create scenario .
FWIW, this all sounds like the best approach to me, given the
considerations you explained. Thanks for writing it up.
>  https://review.opendev.org/#/c/656885
>  https://review.opendev.org/#/c/709280
>  https://review.opendev.org/#/c/665155
More information about the openstack-discuss