<div dir="ltr">Make sense, Dan.<div><br></div><div>Thanks so much for your help.</div><div><br></div><div>Sergio</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 23, 2018 at 5:01 PM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I tested a code change that essentially reverts<br>
> <a href="https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py</a><br>
><br>
> In other words, with this change metadata tables are not fetched by<br>
> default in API requests. If I understand correctly, metadata is<br>
> fetched in separate queries as the instance object is<br>
> created. Everything seems to work just fine, and I've considerably<br>
> reduced the amount of data fetched from the database, as well as<br>
> reduced the average response time of API requests.<br>
><br>
> Given how simple it is and the results I'm getting, I don't see any<br>
> reason not to patch my clusters with this change.<br>
><br>
> Do you guys see any other impact this change could have? Anything that<br>
> it could potentially break?<br>
<br>
This is probably fine as a bandage fix, but it's not the right one for<br>
upstream, IMHO. By doing what you did, you cause two RPC round-trips to<br>
fetch the instance and then the metadata every single time the metadata<br>
API is hit (not including the cache). By converting the DB load to do<br>
the two-step, we still hit the DB twice, but only one RPC round-trip,<br>
which will be much more efficient especially at load/scale.<br>
<br>
--Dan<br>
</blockquote></div>