Open Stack

Assaf, thanks for driving this session.

As a newbie to the design sessions, I think presenting a brief "context"
up-front is helpful. IMO the key word here is "brief" (5 min or less for
example) and furthermore should not open the floor for digression given
the short time-frame we have per session. Some of us will be experts on
the topic, others of us will not have had time to do the proper research
before heading into the session. This "intro" gets us all on the same page,
or closer to it.

Finally, it might be nice to collaborate on the intro content with the main
players of the session topic. Not saying the intro needs to be reviewed,
but typically it seems there are a few individuals with vested
interest / knowledge in the space and it would be nice if they could work
together on developing the content.


On 5/6/16 2:38 PM, Assaf Muller wrote:
> 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/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>