On Fri, Mar 16, 2018 at 12:04 AM, Matt Riedemann <mriede...@gmail.com>
wrote:
On 3/15/2018 3:30 PM, melanie witt wrote:
* We don't need to block bandwidth-based scheduling support for
doing port creation in conductor (it's not trivial), however, if
nova creates a port on a network with a QoS policy, nova is going
to have to munge the allocations and update placement (from
nova-compute) ... so maybe we should block this on moving port
creation to conductor after all
This is not the current direction in the spec. The spec is *large*
and detailed, and this is one of the things being discussed in there.
For the latest on all of it, gonna need to get caught up on the spec.
But it won't be updated for awhile because Brother Gib is on vacation.
In the current state of the spec I try to keep this case out of scope
[1]. Having QoS policy requires a special port or network and nova
server create with network_id only expected to work is simple network
and port setup. If the user want some special port (like SRIOV) she has
to pre-create that port in neutron anyhow.
Cheers,
gibi
[1]
https://review.openstack.org/#/c/502306/18/specs/rocky/approved/bandwidth-resource-provider.rst@126
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
