<div dir="ltr"><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">1. Fail in the API saying you can't rebuild with a new image with new <br>required traits.  </blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"> </blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Pros:
- Simple way to keep the new image off a host that doesn't support it.<br>- Similar solution to volume-backed rebuild with a new image. </blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"> </blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Cons:
- Confusing user experience since they might be able to rebuild with <br>some new images but not others with no clear explanation about the <br>difference.</blockquote><br></div><div><br></div>Still want to get thoughts on Option 1 from the community, the only main con can be addressed by a better error message.<div><br></div><div>My main concern is the amount of complexity being introduced now but also what we are setting ourselfs up for the future.</div><div><br></div><div>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.</div><div><br></div><div>IMHO, i dont see a whole lot of benefit when weighing against the cost. Feedback is appreciated. :)</div><div><br></div><div>Arvind</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 23, 2018 at 3:02 PM, Eric Fried <span dir="ltr"><<a href="mailto:openstack@fried.cc" target="_blank">openstack@fried.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">> for the GET<br>
> /resource_providers?in_tree=<<wbr>CN_UUID>&required=<IMAGE_<wbr>TRAITS>, nested<br>
> resource providers and allocation pose a problem see #3 above.<br>
<br>
</span><span class="im HOEnZb">This *would* work as a quick up-front check as Jay described (if you get<br>
no results from this, you know that at least one of your image traits<br>
doesn't exist anywhere in the tree) except that it doesn't take sharing<br>
providers into account :(<br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Arvind N</div>
</div>