[nova][neutron] nova scheduling support for routed networks

Bal√°zs Gibizer balazs.gibizer at est.tech
Wed Feb 26 12:06:27 UTC 2020


Hi,

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 [1]
Adam's (rm_work) effort to have this as a a new scheduler hint and a 
new scheduler filter [2]

We had a good discussion on #openstack-nova [3] about the possible way 
forward with Sean and Adam. Here is a summary and my proposed way 
forward.

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 [1] and 
[2] 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[1] 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 
attribute

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 [1] 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 [4].

Cheers,
gibi


[1] https://review.opendev.org/#/c/656885
[2] https://review.opendev.org/#/c/709280
[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-02-26.log.html#t2020-02-26T10:18:18
[4] https://review.opendev.org/#/c/665155





More information about the openstack-discuss mailing list