On 2/26/20 04:06, Balázs Gibizer wrote:
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].
FWIW, this all sounds like the best approach to me, given the considerations you explained. Thanks for writing it up.
Cheers, -melanie
[1] https://review.opendev.org/#/c/656885 [2] https://review.opendev.org/#/c/709280 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2... [4] https://review.opendev.org/#/c/665155