Enhance support for ports having resource request

Registered by Balazs Gibizer on 2019-03-20

The Nova REST API microversion 2.72, added in Stein, supports creating server with ports having resource request. However multiple enhancement can be made top of this feature. This blueprint aims the improve the feature with the following changes:

* Use placement to figure out which RP fulfills a port resource request (currently it is done by Nova). This requires the Placement bp https://blueprints.launchpad.net/nova/+spec/placement-resource-provider-request-group-mapping-in-allocation-candidates to be implemented first.

* Support ports in multisegment networks where more than one segment mapped to a physnet. This requires the Placement bp https://blueprints.launchpad.net/nova/+spec/any-traits-in-allocation-candidates-query to be implemented first.

* Supporting SRIOV ports with resource request requires virt driver support (currently supported by libvirt driver) to include the parent interface name to the descriptor of the PCI device represents VFs. Introduce a new TRAIT based capability to the virt drivers to report if they support SRIOV port with resource request to be able to drive the scheduling of server using such ports. Today only the pci_claim stops a boot if the virt driver does not support the feature and that leads to reschedule.

* Optimize the neutron calls in the nova api ( in instance_has_port_with_resource_request() [1]) by using the the instance info cache. Look at the instance.info_cache.network_info[].profile and check for the allocation key in it. If it is there then this instance has port with resource allocation. If it is not there then a) it is shelve offloaded and we have to hit neutron, b) it is not shelve offloaded and then we know this instance has no port with resource request.

* Support attaching a port to a server where the port has resource request. This needs a way to increase the allocation of the running servers. So this requires the in_tree allocation candidate support from placement that was implemented in Stein https://blueprints.launchpad.net/nova/+spec/alloc-candidates-in-tree Also this operation can only be supported if the new, increased allocation still fits to the current compute the server is running on.

* Support attaching a network to a server where the network has a (default) QoS minimum bandwidth rule.

* Support creating a server with a network that has a (default) QoS minimum bandwidth rule. This requires to move the port create from the nova-compute to the nova-conductor first.

* Automatically set group_policy if more than one RequestGroup is generated for an allocation_candidate query in nova. This first needs an agreement what is a good default value for such policy.

Note: that this is a list of possible improvement identified during Stein. We might want to define a smaller scope for Train and prioritize the items.

Note: Supporting server move operations are covered with a separate bp https://blueprints.launchpad.net/nova/+spec/support-server-move-operations-with-ports-having-resource-request

[1] https://github.com/openstack/nova/blob/64b4f41b24bf876294d1e587909ab911ce8e0b48/nova/api/openstack/common.py#L567

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Balazs Gibizer
Direction:
Needs approval
Assignee:
Balazs Gibizer
Definition:
New
Series goal:
Accepted for train
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

efried 20190423 - set series goal to Train so this shows up on the radar for discussion, understanding that the scope may exceed Train.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.