[RFE] Add a neutron port-scheduler component

Bug #1469668 reported by Kevin Benton on 2015-06-29
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Unassigned

Bug Description

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.

Changed in neutron:
assignee: nobody → Kevin Benton (kevinbenton)
Kyle Mestery (mestery) wrote :

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

Changed in neutron:
status: New → Confirmed
Doug Wiegley (dougwig) wrote :

Approved.

Changed in neutron:
status: Confirmed → Triaged
importance: Undecided → High
Carl Baldwin (carl-baldwin) wrote :

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

tags: added: rfe-approved
removed: rfe
Changed in neutron:
importance: High → Wishlist
Changed in neutron:
milestone: none → mitaka-1

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.

summary: - Add a neutron port-scheduler component
+ [RFE] Add a neutron port-scheduler component

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

Changed in neutron:
milestone: mitaka-1 → mitaka-2
Changed in neutron:
milestone: mitaka-2 → mitaka-3

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

Changed in neutron:
status: Triaged → Won't Fix
assignee: Kevin Benton (kevinbenton) → nobody
milestone: mitaka-3 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers