Open Stack

On Tue, Apr 24, 2018 at 9:08 AM, Alex Xu <soulxu at gmail.com> wrote:
> 
> 
> 2018-04-24 5:51 GMT+08:00 Arvind N <arvindn05 at gmail.com>:
>> 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:
>> 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.
>> 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.
> 
> 
> Yes, that is the case what I said, and none of #1,2,3,4 and the 
> proposal in this threads works also.
> 
> The problem isn't just checking the traits in the nested resource 
> provider. We also need to ensure the trait in the exactly same child 
> resource provider. Or we need to adjust allocations for the child 
> resource provider.

I agree that in_tree only ensure that the compute node tree has the 
required traits but it does not take into account that only some of 
those RPs from the tree provides resources for the current allocation. 
The algorithm Eric provided in a previous mail do the filtering for the 
RPs that are part of the instance allocation so that sounds good to me.

I think we should not try to adjust allocations during a rebuild. 
Changing the allocation would mean it is not a rebuild any more but a 
resize.

Cheers,
gibi

> 
> 
>> 
>> 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>