Lance Bragstad lbragstad@gmail.com wrote:
Hi all,
The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0].
During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes):
- Moving legacy clients to python-openstackclient
- Cleaning up resources when deleting a project
- Service-side health checks
I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here.
Does anyone have strong opinions either way about the goals listed above?
I'm a fan of 3. service-side health checks, since I've been having discussions about this with various parties at the last 3--6 (I lost count) Forum / PTG events, and every time there seems to have been a decent amount of interest, e.g.
- Deployment solutions have a clear motive for being able to programmatically determine a more accurate picture of the health of services, e.g. k8s-based deployments like Airship where containers would benefit from more accurate liveness probes.
- The Self-healing SIG is obviously a natural customer for this functionality, since before you can heal you need to know what exactly needs healing.
- It could benefit specific projects such as Vitrage, Horizon, and Monasca, and also automated tests / CI.
Other factors it has in its favour as a community goal is that it's not too ambitious as to prevent a significant amount of progress in one cycle, and also progress should be easily measurable.
FWIW here's some history ... For a good while we got stuck bike-shedding the spec:
https://review.openstack.org/#/c/531456/
but in the API SIG session in Denver, we managed to break the deadlock and agreed to do the simplest thing which could possibly work in order to move forwards:
https://etherpad.openstack.org/p/api-sig-stein-ptg
Yes, there are many unresolved questions about the long-term design, but we decided to avoid any further paralysis and instead forge ahead based on the following principles:
- The existing oslo.middleware mechanism is a good start, so just add a /v2 endpoint to avoid breaking existing consumers.
- Only worry about API services for now.
- Don't worry about authentication yet.
- Endpoints should only report on their own health, not on the health of dependencies / related services.
In Berlin Graham (@mugsie) pushed a very rough prototype to Gerrit:
https://review.openstack.org/#/c/617924/
There's a story in StoryBoard tracking all of this. I've just updated it in an attempt to capture all the relevant history: