<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 17, 2021 at 5:52 PM Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On 11/17/21 10:54 PM, Dan Smith wrote:<br>
>> I don't think we rely on /healthcheck -- there's nothing healthy about<br>
>> an API endpoint blindly returning a 200 OK.<br>
>><br>
>> You might as well just hit / and accept 300 as a code and that's<br>
>> exactly the same behaviour.  I support what Sean is bringing up here<br>
>> and I don't think it makes sense to have a noop /healthcheck that<br>
>> always gives a 200 OK...seems a bit useless imho<br>
> <br>
> Yup, totally agree. Our previous concerns over a healthcheck that<br>
> checked all of nova returning too much info to be useful (for something<br>
> trying to figure out if an individual worker is healthy) apply in<br>
> reverse to one that returns too little to be useful.<br>
> <br>
> I agree, what Sean is working on is the right balance and that we should<br>
> focus on that.<br>
> <br>
> --Dan<br>
> <br>
<br>
That's not the only thing it does. It also is capable of being disabled,<br>
which is useful for maintenance: one can gracefully remove an API node<br>
for removal this way, which one cannot do with the root.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">I feel like this should be handled by whatever layer that needs to drain requests for maintenance, otherwise also it might just be the same as turning off the service, no?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Mohammed Naser<br>VEXXHOST, Inc.</div>