<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 1:18 AM Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Apr 22, 2019 at 12:25 PM Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> wrote:<br>
><br>
><br>
><br>
> On 4/22/19 12:53 PM, Alex Schultz wrote:<br>
> > On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> wrote:<br>
> >><br>
> >><br>
> >><br>
> >> On 4/20/19 1:38 AM, Michele Baldessari wrote:<br>
> >>> On Fri, Apr 19, 2019 at 03:20:44PM -0700, <a href="mailto:iain.macdonnell@oracle.com" target="_blank">iain.macdonnell@oracle.com</a> wrote:<br>
> >>>><br>
> >>>> Today I discovered that this problem appears to be caused by eventlet<br>
> >>>> monkey-patching. I've created a bug for it:<br>
> >>>><br>
> >>>> <a href="https://bugs.launchpad.net/nova/+bug/1825584" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1825584</a><br>
> >>><br>
> >>> Hi,<br>
> >>><br>
> >>> just for completeness we see this very same issue also with<br>
> >>> mistral (actually it was the first service where we noticed the missed<br>
> >>> heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,<br>
> >>> although I have not personally observed it there yet.<br>
> >><br>
> >> Is Mistral also mixing eventlet monkeypatching and WSGI?<br>
> >><br>
> ><br>
> > Looks like there is monkey patching, however we noticed it with the<br>
> > engine/executor. So it's likely not just wsgi.  I think I also saw it<br>
> > in the ironic-conductor, though I'd have to try it out again.  I'll<br>
> > spin up an undercloud today and see if I can get a more complete list<br>
> > of affected services. It was pretty easy to reproduce.<br>
><br>
> Okay, I asked because if there's no WSGI/Eventlet combination then this<br>
> may be different from the Nova issue that prompted this thread. It<br>
> sounds like that was being caused by a bad interaction between WSGI and<br>
> some Eventlet timers. If there's no WSGI involved then I wouldn't expect<br>
> that to happen.<br>
><br>
> I guess we'll see what further investigation turns up, but based on the<br>
> preliminary information there may be two bugs here.<br>
><br>
<br>
So I wasn't able to reproduce the ironic issues yet. But it's the<br>
mistral executor and nova-api which exhibit the issue on the<br>
undercloud.<br>
<br>
mistral/executor.log:2019-04-22 22:40:58.321 7 ERROR<br>
oslo.messaging._drivers.impl_rabbit [-]<br>
[b7b4bc40-767c-4de1-b77b-6a5822f6beed] AMQP server on<br>
undercloud-0.ctlplane.localdomain:5672 is unreachable: [Errno 104]<br>
Connection reset by peer. Trying again in 1 seconds.:<br>
ConnectionResetError: [Errno 104] Connection reset by peer<br>
<br>
<br>
nova/nova-api.log:2019-04-22 22:38:11.530 19 ERROR<br>
oslo.messaging._drivers.impl_rabbit<br>
[req-d7767aed-e32d-43db-96a8-c0509bfb1cfe<br>
9ac89090d2d24949b9a1e01b1afb14cc 7becac88cbae4b3b962ecccaf536effe -<br>
default default] [c0f3fe7f-db89-42c6-95bd-f367a4fbf680] AMQP server on<br>
undercloud-0.ctlplane.localdomain:5672 is unreachable: Server<br>
unexpectedly closed connection. Trying again in 1 seconds.: OSError:<br>
Server unexpectedly closed connection<br>
<br>
The errors being thrown are different perhaps it is two different problems.<br>
<br></blockquote><div><br></div><div>Correct, I think our original issue with erratic AMQP hearbeats and mod_wsgi</div><div>was due to a change in how we run healthcheck in Stein in TripleO-deployed</div><div>environments, so different to what Iain originally experienced it seems...</div><div><br></div><div>For the record, up to Rocky, we used to run healthcheck scripts<br>every 30 seconds, which guarantees that eventlet will wake up and<br>send an AMQP heartbeat packet if a service had no AMQP traffic in the last<br>15s. It also guarantees that any incoming AMQP heartbeat packet from<br>rabbitmq will be processed in at most 30s.<br><br>In Stein, our healthchecks are now triggered via systemd timers, and the</div><div>current time setting is too high to guarantee that mod_wsgi will always</div><div>wake up on time to send/receive AMQP heartbeats to/from rabbitmq</div><div>when there's no traffic.</div><div><br></div><div>The fix is being tracked in <a href="https://bugs.launchpad.net/tripleo/+bug/1826281">https://bugs.launchpad.net/tripleo/+bug/1826281</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
-Alex<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Damien<br></div></div></div></div></div>