Open Stack

Adding correct subject tags because I replied to the original email.  I
blame you Susanne!

On Thu, 2014-08-28 at 23:47 -0500, Brandon Logan wrote:
> I'm not sure exactly how many design sessions will be available but it
> seems like 2 for Neutron LBaaS and 2 for Octavia will be hard to
> accomplish.  Neutron LBaaS had 2 in Atlanta didn't it?  One broad one
> ofr Neutron LBaaS and one more specific to TLS and L7.  I'm totally on
> board for having 2 for each though.  I just think since Octavia is still
> just an idea at this point, it'd be hard getting space and time for a
> design session for it, much less 2.  Doesn't stop us from doing the pods
> or ad hoc sessions though.
> 
> As for topics:
> Neutron LBaaS
> 1) I've been wanting to try and solve the problem (at least I think it
> is a problem) of drivers being responsible for managing the status of
> entities.  In my opinion, Neutron LBaaS should be as consistent as
> possible not matter what drivers are being used.  This is caused by
> supporting both Asynchronous and Synchronous drivers.  I've got some
> ideas on how to solve this.
> 2) Different status types on entities.  Operating status and
> Provisioning status.
> 
> Octavia
> I hope we have gotten far enough along this to have some really detailed
> design discussions.  Hopefully we are within reach of a 0.5 milestone.
> Other than that, too early to tell what exact kind of design talks we
> will need.
> 
> Thanks,
> Brandon
> 
> On Thu, 2014-08-28 at 10:49 -0400, Susanne Balle 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
>