Open Stack

# Questions
> What's the status of shared resource providers? Did we even talk
> about that in Dublin?


In terms of bug fixes related to allocation candidates, I'll try to answer
that question :)
Most of the bugs that have been reported in
https://bugs.launchpad.net/nova/+bug/1731072 are sorted out and already
fixed in Queens.

But we have some items left.

* https://review.openstack.org/#/c/533396
AllocationCandidates.get_by_filters ignores shared RPs when the RC exists
in both places

* https://review.openstack.org/#/c/519601/
* https://review.openstack.org/#/c/533437/
AllocationCandidates.get_by_filters does not handle indirectly connected
sharing RPs
-> In the PTG, we discussed if we need “anchor” RPs in the response of the
API, and if I get it correctly the agreement was "let’s re-open this once
we face a concrete use case." I have updated the patches according to that
conclusion.

* https://review.openstack.org/#/c/533195/
Placement returns no allocation candidate for request that needs both
compute resources and custom shared resources
-> This is already fixed, and trivial comment fix is left and ready for
review.

* No fix proposed - https://bugs.launchpad.net/nova/+bug/1724633
AllocationCandidates.get_by_filters hits incorrectly when traits are split
across the main RP and aggregates
-> This is hard to fix as long as traits belong not to resource classes but
to resource providers. While the current design allows a consumer to pick
resource classes from multiple resource providers (in the same aggregate),
we have no way to know which trait corresponds to which resource class.

Besides these bugs, how we collaborate and merge existing logic of shared
resource provider and now being constructed logic of nested resource
provider remains one of the challenges in Rocky in my understanding.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180312/e7390436/attachment.html>