Re: [openstack-dev] [octavia] Optimize the query of the octavia database

[Erik Olof Gunnar Andersson]

This was solved in neutron-lbaas recently, maybe we could adopt the same method 
for Octavia?

Sent from my iPhone

On Sep 13, 2018, at 4:54 AM, Jeff Yang 
mailto:yjf1970231...@gmail.com>> wrote:


Hi, All

As octavia resources increase, I found that running the "openstack loadbalancer 
list" command takes longer and longer. Sometimes a 504 error is reported.

By reading the code, I found that octavia will performs complex left outer join 
queries when acquiring resources such as loadbalancer, listener, pool, etc. in 
order to only make one trip to the database.
Reference code: http://paste.openstack.org/show/730022 Line 133
Generated SQL statements: http://paste.openstack.org/show/730021

So, I suggest that adjust the query strategy to provide different join queries 
for different resources.

https://storyboard.openstack.org/#!/story/2003751

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Problems with all OpenStack APIs & uwsgi with Content-Lenght and connection reset by peer (ie: 104)

[Erik Olof Gunnar Andersson]

I noticed something similar when deploying Keystone using nginx in the lab, and 
pretty sure I fixed it by setting  uwsgi_ignore_client_abort to on.
http://nginx.org/en/docs/http/ngx_http_uwsgi_module.html

In addition to that flag I also have
client_header_buffer_size 64k;

uwsgi_buffer_size 8k;
uwsgi_read_timeout600;
uwsgi_send_timeout600;

Best Regards, Erik Olof Gunnar Andersson

-Original Message-
From: Thomas Goirand <z...@debian.org> 
Sent: Wednesday, May 2, 2018 11:28 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] Problems with all OpenStack APIs & uwsgi with 
Content-Lenght and connection reset by peer (ie: 104)

On 05/02/2018 10:25 AM, Chris Dent wrote:
> On Wed, 2 May 2018, Thomas Goirand wrote:
> 
>> What was disturbing was that, doing the same request with curl worked 
>> perfectly. Even more disturbing, it looked like I was having the 
>> issue nearly always in virtualbox, but not always in real hardware, 
>> where it sometimes worked.
> 
> What was making the request in the first place? It fails in X, but 
> works in curl. What is X?

For example, nova-compute querying nova-placement-api.
Another example: openstackclient. It happened to me trying to configure 
keystone when running puppet-openstack, for example, but on the command line 
directly as well, simply trying to add users, projects, etc. This looks like to 
me as a general problem in all of the OpenStack WSGI applications.

>> Anyway, finally, I figured out that adding:
>>
>> --rem-header Content-Lenght
> 
> You added this arg to what?

As a parameter to uwsgi, so that it removes the Content-Lenght that the WSGI 
application sends.

>> This however, looks like a workaround rather than a fix, and I wonder 
>> if there's a real issue somewhere that needs to be fixed in a better 
>> way, maybe in openstackclient or some other component...
> 
> Yeah, it sounds like something could be setting a bad value for the 
> content length header and uwsgi is timing out while trying to read 
> that much data (meaning, it is believing the content-length header) 
> but there isn't anything actually there.
> 
> Another option is that there are buffer size problems in the uwsgi 
> configuration but it's hard to speculate because it is not clear what 
> requests and tools you're actually talking about here.

When attempting to google for the issue, I saw a lot of people that had this 
problem fixed by adding --buffer-size 65535, as the default 4k header of uwsgi 
was not enough. I also have this option set, as it seems a reasonable thing to 
have, but that was not enough to fix the problem.
Only the --rem-header thing did.

If you want to try, you can simply use the stretch-queens.debian.net repository 
with Glance (or simply Debian Sid), and edit /etc/glance/glance-api-wsgi.ini to 
change the uwsgi parameters (I've just switched Glance to uwsgi, since it now 
works...). I haven't checked with Glance, but since I saw the problem with 
nova-placement-api, cinder-api and keystone, I don't see why it wouldn't happen 
there.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [designate] Meeting Times - change to office hours?

[Erik Olof Gunnar Andersson]

I can do anytime ranging from 16:00 UTC to 03:00 UTC, Mon-Fri, maybe up to 
07:00 UTC assuming that it's once bi-weekly.


From: Jens Harbott 
Sent: Monday, April 23, 2018 10:49:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] Meeting Times - change to office hours?

2018-04-23 13:11 GMT+02:00 Graham Hayes :
> Hi All,
>
> We moved our meeting time to 14:00UTC on Wednesdays, but attendance
> has been low, and it is also the middle of the night for one of our
> cores.
>
> I would like to suggest we have an office hours style meeting, with
> one in the UTC evening and one in the UTC morning.
>
> If this seems reasonable - when and what frequency should we do
> them? What times suit the current set of contributors?

My preferred range would be 06:00UTC-14:00UTC, Mon-Thu, though
extending a couple of hours in either direction might be possible for
me, too.

If we do alternating times, with the current amount of work happening
we maybe could make each of them monthly, so we end up with a roughly
bi-weekly schedule.

I also have a slight preference for continuing to use one of the
meeting channels as opposed to meeting in the designate channel, if
that is what "office hours style meeting" is meant to imply.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev