Open Stack

On Mon, May 9, 2016 at 1:28 PM, Boden Russell <bodenvmw at gmail.com> wrote:
> 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.

That's good input. For future reference I think you will find that if
you reach out to session chairs, no one will say no :)

>
>
> 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
>>
>
>
> __________________________________________________________________________
> 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