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
__________________________________________________________________________ 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