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