[RFE] Add a neutron port-scheduler component

[Kevin Benton]

Both the get-me-a-network spec and the use cases laid out by several large deployers (Neutron networks limited to a single rack or other subset of datacenter) could benefit from a port scheduler. This port scheduler would allow Nova (or another caller) to request a port via port create without providing a network ID. The port scheduler would then populate the appropriate network ID depending on the request details and port creation would continue as normal.

In lieu of the network ID, the client can pass optional hints to constrain the network selection (e.g. an external network that the network can reach). If the client doesn't pass any hints, this would become the 'get-me-a-network' use case where it's entirely up to Neutron.

In order to satisfy the use case where not all Neutron networks are available everywhere, this scheduler should also expose an API that allows a Nova scheduling filter to be written that can ask Neutron which hosts can be used for the Neutron port details it was given.

[Kyle Mestery (mestery)]

This sounds like it will make the life of operators much easier.

[Doug Wiegley (dougwig)]

Approved.

[Carl Baldwin (carl-baldwin)]

This relates to the network segment rfe [1] that came from operators at the Liberty summit in Vancouver. Specifically, the hints and nova scheduler parts in this description are aimed specifically at the nova scheduling part of that rfe.

[1] https://bugs.launchpad.net/neutron/+bug/1458890

[Armando Migliaccio (armando-migliaccio)]

I know that some Nova folks might be opposed to this type of workflow, but let's get the conversation going so that we can achieve consensus quickly.

[Andreas Scheuring (andreas-scheuring)]

Just trying to catch the difference between this proposal and the existng get-me-a-network proposal [1][2]

So if I got it right, [2] proposes
#1 New API "get-me-a-network".
--> takes the same parameters as the network-list API. But it does not allow passing any additional parameters (like I want a network that is attached to an external network) for the user. The only control mechanism is something that the administrator has to predefine somehow.
--> returns: a network

This proposal proposes 2 things:

#2 Update to "Create Port" API:
It's a scheduler that is triggerd on "create port" when no network is specified.
--> takes additional flags or key-values (like SHARED, routed=external), which will be passed to the new scheduler, which then will continue creating the port on a matching network.
--> returns: a port on a network

#3 a new API that takes details of an existing port as argument and returns a list of hosts where this port is available
--> returns: list of hosts

So can we say that #2 replaces #1? So instead of get-me-a-network we implement get-me-a-port (hidden behind create port api) which covers the use case of [2] as well?

[1] http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
[2] https://bugs.launchpad.net/neutron/+bug/1475792

[Armando Migliaccio (armando-migliaccio)]

superseded by the latest direction adopted by the routed network spec, and how get-me-a-network orchestration is going to take place.