Open Stack

I tested a code change that essentially reverts
https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py

In other words, with this change metadata tables are not fetched by default
in API requests. If I understand correctly, metadata is fetched in separate
queries as the instance object is created. Everything seems to work just
fine, and I've considerably reduced the amount of data fetched from the
database, as well as reduced the average response time of API requests.

Given how simple it is and the results I'm getting, I don't see any reason
not to patch my clusters with this change.

Do you guys see any other impact this change could have? Anything that it
could potentially break?


On Mon, Oct 22, 2018 at 10:05 PM Sergio A. de Carvalho Jr. <
scarvalhojr at gmail.com> wrote:

>
> https://bugs.launchpad.net/nova/+bug/1799298
>
> On Mon, Oct 22, 2018 at 9:15 PM Sergio A. de Carvalho Jr. <
> scarvalhojr at gmail.com> wrote:
>
>> Cool, I'll open a bug then.
>>
>> I was wondering if, before joining the metadata tables with the rest of
>> instance data, we could do a UNION, since both tables are structurally
>> identical.
>>
>> On Mon, Oct 22, 2018 at 9:04 PM Dan Smith <dms at danplanet.com> wrote:
>>
>>> > Do you guys see an easy fix here?
>>> >
>>> > Should I open a bug report?
>>>
>>> Definitely open a bug. IMHO, we should just make the single-instance
>>> load work like the multi ones, where we load the metadata separately if
>>> requested. We might be able to get away without sysmeta these days, but
>>> we needed it for the flavor details back when the join was added. But,
>>> user metadata is controllable by the user and definitely of interest in
>>> that code, so just dropping sysmeta from the explicit required_attrs
>>> isn't enough, IMHO.
>>>
>>> --Dan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181023/632104c3/attachment.html>