Open Stack

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.2020-02-26.log.html#t2020-02-26T10:18:18
> [4] https://review.opendev.org/#/c/665155
> 
> 
>