Open Stack

Thanks for the detailed options Matt/eric/jay.

Just few of my thoughts,

For #1, we can make the explanation very clear that we rejected the request
because the original traits specified in the original image and the new
traits specified in the new image do not match and hence rebuild is not
supported.

For #2,

Other Cons:

   1. None of the filters currently make other API requests and my
   understanding is we want to avoid reintroducing such a pattern. But
   definitely workable solution.
   2. If the user disables the image properties filter, then traits based
   filtering will not be run in rebuild case

For #3,

Even though it handles the nested provider, there is a potential issue.

Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), another
one with some kind of offload feature(VF2).(Described by alex)

Initial instance launch happens with VF:1 allocated, rebuild launches with
modified request with traits=HW_NIC_OFFLOAD_X, so basically we want the
instance to be allocated VF2.

But the original allocation happens against VF1 and since in rebuild the
original allocations are not changed, we have wrong allocations.

for #4, there is good amount of pushback against modifying the
allocation_candiadates api to not have resources.

Jay:
for the GET /resource_providers?in_tree=<CN_UUID>&required=<IMAGE_TRAITS>,
nested resource providers and allocation pose a problem see #3 above.

I will investigate erics option and update the spec.
-- 
Arvind N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180423/b6f1fbb6/attachment.html>