On 3/8/2018 6:51 AM, Jay Pipes wrote:
- VGPU_DISPLAY_HEAD resource class should be removed and replaced with
a set of os-traits traits that indicate the maximum supported number of
display heads for the vGPU type
How does a trait express a quantifiable limit? Would we end up have
several different traits with varying levels of limits?
- Multiple agreements about strict minimum bandwidth support feature in
nova - Spec has already been updated accordingly:
https://review.openstack.org/#/c/502306/
- For now we keep the hostname as the information connecting the
nova-compute and the neutron-agent on the same host but we are aiming
for having the hostname as an FQDN to avoid possible ambiguity.
- We agreed not to make this feature dependent on moving the nova
port create to the conductor. The current scope is to support
pre-created neutron port only.
I could rat-hole in the spec, but figured it would be good to also
mention it here. When we were talking about this in Dublin, someone also
mentioned that depending on the network on which nova-compute creates a
port, the port could have a QoS policy applied to it for bandwidth, and
then nova-compute would need to allocate resources in Placement for that
port (with the instance as the consumer). So then we'd be doing
allocations both in the scheduler for pre-created ports and in the
compute for ports that nova creates. So the scope statement here isn't
entirely true, and leaves us with some technical debt until we move port
creation to conductor. Or am I missing something?
- Neutron will provide the resource request in the port API so this
feature does not depend on the neutron port binding API work
- Neutron will create resource providers in placement under the
compute RP. Also Neutron will report inventories on those RPs
- Nova will do the claim of the port related resources in placement
and the consumer_id will be the instance UUID
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
