<div dir="ltr"><div><div><div>Reminder for Operators, Please provide feedback either way.<br><br></div>In cases of rebuilding of an instance using a different image where the image traits have changed between the original launch and the rebuild, is it reasonable to ask to just re-launch a new instance with the new image?<br><br>The argument for this approach is that given that the requirements have changed, we want the scheduler to pick and allocate the appropriate host for the instance. <br><br>The approach above also gives you consistent results vs the other approaches where the rebuild may or may not succeed depending on how the original allocation of resources went.<br><br></div><div>For example(from Alex Xu) ,if you launched an instance on a host which  has two SRIOV nic. One is normal SRIOV nic(A), another one with some kind of offload feature(B). <p style="white-space:pre-wrap;color:rgb(0,0,0);font-family:sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">So, the original request is:
resources=SRIOV_VF:1
The instance gets a VF from the normal SRIOV nic(A).</p><p style="white-space:pre-wrap;color:rgb(0,0,0);font-family:sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">But with a new image, the new request is:
resources=SRIOV_VF:1
traits=HW_NIC_OFFLOAD_XX</p>With all the solutions discussed in the thread, a rebuild request like above may or may not succeed depending on whether during the initial launch whether nic A or nic B was allocated. <br><br>Remember that in rebuild new allocation don't happen, we have to reuse the existing allocations.<br><br></div><div>Given the above background, there seems to be 2 competing options.<br><br>1. Fail in the API saying you can't rebuild with a new image with new required traits.


<br><br></div><div>2. Look at the current allocations for the instance and try to match the new requirement from the image with the allocations.<br></div><div><br></div><div>With #1, we get consistent results in regards to how rebuilds are treated when the image traits changed.<br><br></div><div>With #2, the rebuild may or may not succeed, depending on how well the original allocations match up with the new requirements.<br><br></div><div>#2 will also need to need to account for handling preferred traits or granular resource traits if we decide to implement them for images at some point...<br></div><br><br>[1] <a href="https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/glance-image-traits.html">https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/glance-image-traits.html</a><br>[2] <a href="https://review.openstack.org/#/c/560718/">https://review.openstack.org/#/c/560718/</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 24, 2018 at 6:26 AM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry folks for the late reply, I'll try to also weigh in the Gerrit change.<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Apr 24, 2018 at 2:55 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@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>On 04/23/2018 05:51 PM, Arvind N wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the detailed options Matt/eric/jay.<br>
<br>
Just few of my thoughts,<br>
<br>
For #1, we can make the explanation very clear that we rejected the request because the original traits specified in the original image and the new traits specified in the new image do not match and hence rebuild is not supported.<br>
</blockquote>
<br></span>
I believe I had suggested that on the spec amendment patch. Matt had concerns about an error message being a poor user experience (I don't necessarily disagree with that) and I had suggested a clearer error message to try and make that user experience slightly less sucky.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For #3,<br>
<br>
Even though it handles the nested provider, there is a potential issue.<br>
<br>
Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), another one with some kind of offload feature(VF2).(Described by alex)<br>
<br>
Initial instance launch happens with VF:1 allocated, rebuild launches with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want the instance to be allocated VF2.<br>
<br>
But the original allocation happens against VF1 and since in rebuild the original allocations are not changed, we have wrong allocations.<br>
</blockquote>
<br></span>
Yep, that is certainly an issue. The only solution to this that I can see would be to have the conductor ask the compute node to do the pre-flight check. The compute node already has the entire tree of providers, their inventories and traits, along with information about providers that share resources with the compute node. It has this information in the ProviderTree object in the reportclient that is contained in the compute node resource tracker.<br>
<br>
The pre-flight check, if run on the compute node, would be able to grab the allocation records for the instance and determine if the required traits for the new image are present on the actual resource providers allocated against for the instance (and not including any child providers not allocated against).<br>
<br></blockquote><div><br></div></span><div>Yup, that. We also have pre-flight checks for move operations like live and cold migrations, and I'd really like to keep all the conditionals in the conductor, because it knows better than the scheduler which operation is asked.<br></div><div>I'm not really happy with adding more in the scheduler about "yeah, it's a rebuild, so please do something exceptional", and I'm also not happy with having a filter (that can be disabled) calling the Placement API.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or... we chalk this up as a "too bad" situation and just either go with option #1 or simply don't care about it.</blockquote><div><br></div></span><div>Also, that too. Maybe just provide an error should be enough, nope? Operators, what do you think ? (cross-calling openstack-operators@)<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div> -Sylvain<br><br></div></font></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-8052436661673148862HOEnZb"><div class="m_-8052436661673148862h5"><br>
<br>
Best,<br>
-jay<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></span></div><br></div></div>
<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.<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>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Arvind N</div>
</div>