[tc][all][self-healing-sig] Service-side health checks community goal for Train cycle
On 1/28/19 5:34 AM, Chris Dent wrote:
> On Mon, 28 Jan 2019, Jean-Philippe Evrard wrote:
>> It is not a non-starter. I knew this would show up :)
>> It's fine that some projects do differently (for example swift has
>> different middleware, keystone is not using paste).
> Tangent so that people are clear on the state of Paste and
> I recommend projects move away from using either.
> Until recently both were abandonware, not receiving updates, and
> had issues working with Python3.
> I managed to locate maintainers from a few years ago, and negotiated
> to bring them under some level of maintenance, but in both cases the
> people involved are only interested in doing limited management to
> keep the projects barely alive.
> pastedeploy (the thing that is more often used in OpenStack, and is
> usually used to load the paste.ini file and doesn't have to have a
> dependency on paste itself) is now under the Pylons project:
> Paste itself is with me: https://github.com/cdent/paste
>> I think it's also too big of a change to move everyone to one single
>> technology in a cycle :) Instead, I want to focus on the real use case
>> for people (bringing a common healthcheck "api" itself), which doesn't
>> matter on the technology.
> I agree that the healthcheck change can and should be completely
> separate from any question of what is used to load middleware.
> That's the great thing about WSGI.
> As long as the healthcheck tooling presents are "normal" WSGI
> interface it ought to either "just work" or be wrappable by other tooling,
> so I wouldn't spend too much time making a survey of how people are
> doing middleware.
So should that question be re-worded? The current Keystone answer is
accurate but unhelpful, given that I believe Keystone does enable the
healthcheck middleware by default:
Since what we care about isn't the WSGI implementation but the
availability of the feature, shouldn't that question be more like
"Project enables healthcheck middleware by default"? In which case
Keystone's answer becomes a simple "yes" and Manila's a simple "no".
> The tricky part (but not that tricky) will be with managing how the
> "tests" are provided to the middleware.