<div dir="ltr"><div><div>Isnt this an existing issue with traits specified in flavor as well?<br><br></div>Server is created using flavor1 requiring trait A on RP1. Before the rebuild is called, the underlying RP1 can be updated to remove trait A and when a rebuild is requested(regardless of whether the image is updated or not), we skip scheduling and allow the rebuild to go through. <br><br>Now, even though the flavor1 requests trait A, the underlying RP1 does not have that trait the rebuild will succeed...<br><br></div>I think maybe there should be some kind of report or query which runs periodically to ensure continued conformance with respect to instance running and their traits. But since traits are intend to provide hints for scheduling, this is different problem to solve IMO.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 2, 2018 at 3:45 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5/2/2018 5:39 PM, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My personal preference is to add less technical debt and go with a solution that checks if image traits have changed in nova-api and if so, simply refuse to perform a rebuild.<br>
</blockquote>
<br></span>
So, what if when I created my server, the image I used, let's say image1, had required trait A and that fit the host.<br>
<br>
Then some external service removes (or somehow changes) trait A from the compute node resource provider (because people can and will do this, there are a few vmware specs up that rely on being able to manage traits out of band from nova), and then I rebuild my server with image2 that has required trait A. That would match the original trait A in image1 and we'd say, "yup, lgtm!" and do the rebuild even though the compute node resource provider wouldn't have trait A anymore.<br>
<br>
Having said that, it could technically happen before traits if the operator changed something on the underlying compute host which invalidated instances running on that host, but I'd think if that happened the operator would be migrating everything off the host and disabling it from scheduling before making whatever that kind of change would be, let's say they change the hypervisor or something less drastic but still image property invalidating.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Arvind N</div>
</div>