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 <[email protected]> > > 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
