Open Stack

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:
>
>    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.
>


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.



> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180424/bbbd392a/attachment.html>