osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Mon, 2019-02-11 at 16:28 -0600, Ben Nemec wrote:
> 
> 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
> > 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.
> 
> 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: 
> https://docs.openstack.org/keystone/latest/admin/health-check-middleware.html
> 
> 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.
> > 

Totally fair, to me.