Open Stack

Lance Bragstad <lbragstad at 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): 
>
>   1. Moving legacy clients to python-openstackclient 
>   2. Cleaning up resources when deleting a project 
>   3. 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? 
>
>[0] https://etherpad.openstack.org/p/BER-t-series-goals 

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: 

    https://storyboard.openstack.org/#!/story/2001439