Open Stack

>
> 1. Fail in the API saying you can't rebuild with a new image with new
> required traits.



Pros: - Simple way to keep the new image off a host that doesn't support it.
> - Similar solution to volume-backed rebuild with a new image.



Cons: - Confusing user experience since they might be able to rebuild with
> some new images but not others with no clear explanation about the
> difference.



Still want to get thoughts on Option 1 from the community, the only main
con can be addressed by a better error message.

My main concern is the amount of complexity being introduced now but also
what we are setting ourselfs up for the future.

When/If we decide to support forbidden traits, granular resource traits,
preferred traits etc based on image properties, we would have to handle all
those complexities for the rebuild case and possibly re-implement some of
the logic already within placement to handle these cases.

IMHO, i dont see a whole lot of benefit when weighing against the cost.
Feedback is appreciated. :)

Arvind

On Mon, Apr 23, 2018 at 3:02 PM, Eric Fried <openstack at fried.cc> wrote:

> > for the GET
> > /resource_providers?in_tree=<CN_UUID>&required=<IMAGE_TRAITS>, nested
> > resource providers and allocation pose a problem see #3 above.
>
> This *would* work as a quick up-front check as Jay described (if you get
> no results from this, you know that at least one of your image traits
> doesn't exist anywhere in the tree) except that it doesn't take sharing
> providers into account :(
>
> __________________________________________________________________________
> 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
>



-- 
Arvind N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180423/79efe380/attachment.html>