On Mon, May 9, 2016 at 1:28 PM, Boden Russell <boden...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
