[RFE] Instance scheduling based on Neutron properties

[Andreas Scheuring]

Add support to allow nova scheduler place instances along available neutron properties.

Use case:
- Scheduling along physical network: A certain network (e.g. your fast 100Gbit network) is only available to a subset of the nodes (e.g. per rack).
- Schedulding along QoS attributes: Schedule instances along available bandwidth

Proposal:
Integration might be challenging, as also nova needs to be enhanced with a new filter. Ihar talked to nova folks (Nikola Dipanov, Jay Pipes, Sylvain) but they seemed not to be interested in fulfilling this need right now. However they have a vague idea of a scheduler hook to influence scheduling decisions.

Alternative to nova scheduler hook:
Today scheduling decision is made on resource data reported from nova-cpu to nova scheduler via the message bus. What would be required is a similar reporting from neutron-agent to nova-scheduler. However such a private path might be against the decoupling of nova and neutron, introduce new message topics and so on.

Note: This bug is intended to track all information from Neutron side. It's not meant as a requirement against nova.

[Carl Baldwin (carl-baldwin)]

This has some similarity to a problem I'm working on in the context of this rfe [1]. In that case, it is choosing a network connected to a particular L3 reachability domain that also has IP availability. I'm pursuing the path of modeling the L3 domain explicitly in Neutron but some of the Nova interaction has yet to be worked out.

Tags [2] has been suggested as another possible part of the solution. One might be able to tag a fast network but tags wouldn't be useful for dynamic properties such as available bandwidth.

I had a brief conversation with John Garbutt in Tokyo. He mentioned a desire to move toward a model where the port is created first, configured, and then pass to Nova. I'm not sure how wide-spread that opinion is in Nova. If that were the work-flow, we could provide a nova scheduling filter that given a port, could filter down to the set of hosts which are compatible given whatever properties the port has.

There is a problem with scheduling the port up front to a network and then passing it to Nova. The problem is if there are multiple networks that the port could be scheduled to, by selecting one of them before nova has had a chance to get involved we've just unnecessarily constrained the scheduling problem for Nova. But, currently in Neutron, we cannot create a port that is not bound to a network. I actually planned to look in to creating a port that isn't bound to a network yet this week or next.

Keep me in the loop on this one. Also, I'd like Kevin Benton to take a look.

[1] https://bugs.launchpad.net/neutron/+bug/1458890
[2] https://review.openstack.org/#/c/216021/

[Armando Migliaccio (armando-migliaccio)]

As per description, this is not meant to be tracking anything nova-specific, so remove nova from the list of affected projects.

[Armando Migliaccio (armando-migliaccio)]

This looks like it can be addressed in the context of bug 1469668