Open Stack

Thanks so much for the replies, guys.

> Have you debugged to the point of knowing where the initial DB query is
starting from?
>
> Looking at history, my guess is this is the change which introduced it
for all requests:
>
> https://review.openstack.org/#/c/276861/

That is my understanding too. Before, metadata was fetched separately but
this change meant that it both tables are always joined with other instance
data.

I've debugged it to the point where the query gets built, in

https://github.com/openstack/nova/blob/mitaka-eol/nova/db/sqlalchemy/api.py#L2005

which results in a number of left outer joins by the "joinedload" calls,
including to "instance_metadata" and "instance_system_metadata".

Most other tables have a single row for each instance (on our clusters,
anyway), so the impact for us is simply down to metadata.

> Just to be clear, you don't have any modifications to the code anywhere,
do you?

We do have some minor changes to Nova but nothing near instance, metadata
or the ORM code.

Do you guys see an easy fix here?

Should I open a bug report?

On Mon, Oct 22, 2018 at 7:17 PM Dan Smith <dms at danplanet.com> wrote:

> > We haven't been doing this (intentionally) for quite some time, as we
> > query and fill metadata linearly:
> >
> >
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244
> >
> > and have since 2013 (Havana):
> >
> > https://review.openstack.org/#/c/26136/
> >
> > So unless there has been a regression that is leaking those columns back
> > into the join list, I'm not sure why the query you show would be
> > generated.
>
> Ah, Matt Riedemann just pointed out on IRC that we're not doing it on
> single-instance fetch, which is what you'd be hitting in this path. We
> use that approach in a lot of places where the rows would also be
> multiplied by the number of instances, but not in the single case. So,
> that makes sense now.
>
> --Dan
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181022/108e51f4/attachment.html>