[openstack-dev] [Neutron][LBass] Design sessions for Neutron LBaaS. What do we want/need?

Susanne Balle sleipnir012 at gmail.com
Thu Aug 28 19:26:43 UTC 2014


Let's use a different email thread to discuss if Octavia should be part of
the Neutron incubator project right away or not. I would like to keep the
two discussions separate.



Susanne


On Thu, Aug 28, 2014 at 3:20 PM, Stephen Balukoff <sbalukoff at bluebox.net>
wrote:

> Hi Susanne--
>
> Regarding the Octavia sessions:  I think we probably will have enough to
> discuss that we could use two design sessions.  However, I also think that
> we can probably come to conclusions on whether Octavia should become a part
> of Neutron Incubator right away via discussion on this mailing list.  Do we
> want to have that discussion in another thread, or should we use this one?
>
> Stephen
>
>
> On Thu, Aug 28, 2014 at 7:51 AM, Susanne Balle <sleipnir012 at gmail.com>
> wrote:
>
>> With a corrected Subject. Susanne
>>
>>
>>
>> On Thu, Aug 28, 2014 at 10:49 AM, Susanne Balle <sleipnir012 at gmail.com>
>> wrote:
>>
>>>
>>> LBaaS team,
>>>
>>> As we discussed in the Weekly LBaaS meeting this morning we should make
>>> sure we get the design sessions scheduled that we are interested in.
>>>
>>> We currently agreed on the following:
>>>
>>> * Neutron LBaaS. we want to schedule 2 sessions. I am assuming that we
>>> want to go over status and also the whole incubator thingy and how we will
>>> best move forward.
>>>
>>> * Octavia: We want to schedule 2 sessions.
>>> ---  During one of the sessions I would like to discuss the pros and
>>> cons of putting Octavia into the Neutron LBaaS incubator project right
>>> away. If it is going to be the reference implementation for LBaaS v 2 then
>>> I believe Octavia belong in Neutron LBaaS v2 incubator.
>>>
>>> * Flavors which should be coordinated with markmcclain and enikanorov.
>>> --- https://review.openstack.org/#/c/102723/
>>>
>>> Is this too many sessions given the constraints? I am assuming that we
>>> can also meet at the pods like we did at the last summit.
>>>
>>> thoughts?
>>>
>>> Regards Susanne
>>>
>>> Thierry Carrez <thierry at openstack.org>
>>> Aug 27 (1 day ago)
>>>  to OpenStack
>>>  Hi everyone,
>>>
>>> I've been thinking about what changes we can bring to the Design Summit
>>> format to make it more productive. I've heard the feedback from the
>>> mid-cycle meetups and would like to apply some of those ideas for Paris,
>>> within the constraints we have (already booked space and time). Here is
>>> something we could do:
>>>
>>> Day 1. Cross-project sessions / incubated projects / other projects
>>>
>>> I think that worked well last time. 3 parallel rooms where we can
>>> address top cross-project questions, discuss the results of the various
>>> experiments we conducted during juno. Don't hesitate to schedule 2 slots
>>> for discussions, so that we have time to come to the bottom of those
>>> issues. Incubated projects (and maybe "other" projects, if space allows)
>>> occupy the remaining space on day 1, and could occupy "pods" on the
>>> other days.
>>>
>>> Day 2 and Day 3. Scheduled sessions for various programs
>>>
>>> That's our traditional scheduled space. We'll have a 33% less slots
>>> available. So, rather than trying to cover all the scope, the idea would
>>> be to focus those sessions on specific issues which really require
>>> face-to-face discussion (which can't be solved on the ML or using spec
>>> discussion) *or* require a lot of user feedback. That way, appearing in
>>> the general schedule is very helpful. This will require us to be a lot
>>> stricter on what we accept there and what we don't -- we won't have
>>> space for courtesy sessions anymore, and traditional/unnecessary
>>> sessions (like my traditional "release schedule" one) should just move
>>> to the mailing-list.
>>>
>>> Day 4. Contributors meetups
>>>
>>> On the last day, we could try to split the space so that we can conduct
>>> parallel midcycle-meetup-like contributors gatherings, with no time
>>> boundaries and an open agenda. Large projects could get a full day,
>>> smaller projects would get half a day (but could continue the discussion
>>> in a local bar). Ideally that meetup would end with some alignment on
>>> release goals, but the idea is to make the best of that time together to
>>> solve the issues you have. Friday would finish with the design summit
>>> feedback session, for those who are still around.
>>>
>>>
>>> I think this proposal makes the best use of our setup: discuss clear
>>> cross-project issues, address key specific topics which need
>>> face-to-face time and broader attendance, then try to replicate the
>>> success of midcycle meetup-like open unscheduled time to discuss
>>> whatever is hot at this point.
>>>
>>> There are still details to work out (is it possible split the space,
>>> should we use the usual design summit CFP website to organize the
>>> "scheduled" time...), but I would first like to have your feedback on
>>> this format. Also if you have alternative proposals that would make a
>>> better use of our 4 days, let me know.
>>>
>>> Cheers,
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140828/0ce64eba/attachment.html>


More information about the OpenStack-dev mailing list