Open Stack

It is my personal experience that unless I do my homework, design
summit discussions largely go over my head. I'd guess that most people
don't have time to research the topic of every design session they
intend to go to, so for the session I lead I decided to do the
unthinkable and present the context of the discussion [1] with a few
slides [2] (That part of the session took I think 3 minutes). I'd love
to get feedback particularly on that, if people found it useful we may
consider increasing adoption of that habit for the Barcelona design
summit.

The goal for the session was to achieve consensus on the very high
level topics: Do we want to do Neutron diagnostics in-tree and via the
API. I believe that goal was achieved, and the answer to both
questions is 'yes'.

Since there's been at least 4 RFEs submitted in this domain, the next
step is to try and converge on one and iterate on an API. For these
purposes we will be using Hynek's spec, under review here [3]. I was
approached by multiple people that are interested in assisting with
the implementation phase, please say so on the spec so that Hynek will
be able to add you as a contributor.

I foresee a few contention points, chief of which is the abstraction
level of the API and how best to present diagnostics information in a
way that is plugin agnostic. The trick will be to find an API that is
not specific to the reference implementation while still providing a
great user experience to the vast majority of OpenStack users.

A couple of projects in the domain were mentioned, specifically
Monasca and Steth. Contributors from these projects are highly
encouraged to review the spec.

[1] https://etherpad.openstack.org/p/newton-neutron-troubleshooting
[2] https://docs.google.com/presentation/d/1IBVZ6defUwhql4PEmnhy3fl9qWEQVy4iv_IR6pzkFKw/edit?usp=sharing
[3] https://review.openstack.org/#/c/308973/