Open Stack

Alex-

On 04/24/2018 09:21 AM, Alex Xu wrote:
> 
> 
> 2018-04-24 20:53 GMT+08:00 Eric Fried <openstack at fried.cc
> <mailto:openstack at fried.cc>>:
> 
>     > 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.
> 
>     No, we can't get "granular" with image traits.  We accepted this as a
>     limitation for the spawn aspect of this spec [1], for all the same
>     reasons [2].  And by the time we've spawned the instance, we've lost the
>     information about which granular request groups (from the flavor) were
>     satisfied by which resources - retrofitting that information from a new
>     image would be even harder.  So we need to accept the same limitation
>     for rebuild.
> 
>     [1] "Due to the difficulty of attempting to reconcile granular request
>     groups between an image and a flavor, only the (un-numbered) trait group
>     is supported. The traits listed there are merged with those of the
>     un-numbered request group from the flavor."
>     (http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/glance-image-traits.html#proposed-change
>     <http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/glance-image-traits.html#proposed-change>)
>     [2]
>     https://review.openstack.org/#/c/554305/2/specs/rocky/approved/glance-image-traits.rst@86
>     <https://review.openstack.org/#/c/554305/2/specs/rocky/approved/glance-image-traits.rst@86>
> 
> 
> Why we can return a RP which has a specific trait but we won't consume
> any resources on it?
> If the case is that we request two VFs, and this two VFs have different
> required traits, then that should be granular request.

We don't care about RPs we're not consuming resources from.  Forget
rebuild - if the image used for the original spawn request has traits
pertaining to VFs, we folded those traits into the un-numbered request
group, which means the VF resources would have needed to be in the
un-numbered request group in the flavor as well.  That was the
limitation discussed at [2]: trying to correlate granular groups from an
image to granular groups in a trait would require nontrivial invention
beyond what we're willing to do at this point.  So we're limited at
spawn time to VFs (or whatever) where we can't tell which trait belongs
to which.  The best we can do is ensure that the end result of the
un-numbered request group will collectively satisfy all the traits from
the image.  And this same limitation exists, for the same reasons, on
rebuild.  It even goes a bit further, because if there are *other* VFs
(or whatever) that came from numbered groups in the original request, we
have no way to know that; so if *those* guys have traits required by the
new image, we'll still pass.  Which is almost certainly okay.

-efried