[tc][all][self-healing-sig] Service-side health checks community goal for Train cycle

Chris Dent cdent+os at anticdent.org
Mon Jan 28 11:34:02 UTC 2019


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
PasteDeploy.

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:
https://github.com/Pylons/pastedeploy

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.

The tricky part (but not that tricky) will be with managing how the
"tests" are provided to the middleware.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent


More information about the openstack-discuss mailing list