On 5/12/17 12:31 PM, Armando M. wrote:
>
> Please, do provide feedback in case I omitted some other key takeaway.
>
> [1] https://etherpad.openstack.org/p/pike-neutron-diagnostics
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/pike/diagnostics.html
>
Glad you all got a chance to
Hi folks,
At the summit we had a forum session [1] to gather feedback on the current
diagnostics proposal [2] and help the neutron developer team drive the
first implementation of the API proposal.
Two main points were brought for discussion:
1) which diagnostics checks to provide to start with;
Adding diagnostics capabilities to Neutron has been requested by several
recent RFEs. I have tried to consolidate features requested in them and
incorporate points from Austin design session on diagnostics &
troubleshooting into a specification on that topic [1]. If you are
interested in enhanc
On Mon, May 9, 2016 at 1:28 PM, Boden Russell 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 floo
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
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 cont
