Open Stack

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140828/2115ca6a/attachment.html>