<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:comic sans ms,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 1:18 PM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.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">> Tagging with Nova and Neutron as they are mentioned and I thought some<br>
> people from those teams had opinions on this.<br>
<br>
Nova already implements ping() on the compute RPC interface, which we<br>
use to make sure compute waits to start up until conductor is available<br>
to do its bidding. So if a new obligatory RPC server method is actually<br>
added called ping(), it will break us.<br>
<br>
> Can you refresh my memory on why we dropped this before? I recall<br>
> talking about it in Denver, but I can't for the life of me remember<br>
> what the conclusion was. Did we intend to use something else for this<br>
> that has since fallen through?<br>
<br>
The prior conversation I recall was about helm sitting on our bus to<br>
(ab)use our ping method for health checks:<br>
<br>
<a href="https://opendev.org/openstack/openstack-helm/commit/baf5356a4fb61590a95f64a63c0dcabfebb3baaa" rel="noreferrer" target="_blank">https://opendev.org/openstack/openstack-helm/commit/baf5356a4fb61590a95f64a63c0dcabfebb3baaa</a><br>
<br>
I believe that has since been reverted.<br>
<br>
The primary concern was about something other than nova sitting on our<br>
bus making calls to our internal services. I imagine that the proposal<br>
to bake it into oslo.messaging is for the same purpose, and I'd probably<br>
have the same concern. At the time I think we agreed that if we were<br>
going to support direct-to-service health checks, they should be teensy<br>
HTTP servers with oslo healthchecks middleware. Further loading down<br>
rabbit with those pings doesn't seem like the best plan to<br>
me. Especially since Nova (compute) services already check in over RPC<br>
periodically and the success of that is discoverable en masse through<br>
the API.<br>
<br>
--Dan<br>
<br>
</blockquote></div><div><br></div><div><div style="font-family:comic sans ms,sans-serif" class="gmail_default">While initially in favor of this feature Dan's concern has me reconsidering this.</div><div style="font-family:comic sans ms,sans-serif" class="gmail_default"><br></div><div style="font-family:comic sans ms,sans-serif" class="gmail_default">Now I believe that if the purpose of this feature is to check the operational health of a service _using_ oslo.messaging, then I'm against it.   A naked ping to a generic service point in an application doesn't prove the operating health of that application beyond its connection to rabbit.  Connectivity monitoring between an application and rabbit is done using the keepalive connection heartbeat mechanism built into the rabbit protocol, which O.M. supports today.<br></div></div><div><br></div><div><br></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-family:comic sans ms,sans-serif">Ken Giusti  (<a href="mailto:kgiusti@gmail.com" target="_blank">kgiusti@gmail.com</a>)</span></div></div></div></div>