Open Stack

I agree with Brandon that it will be difficult to find spaces for Octavia,
and the pod is a valid option.
Nevertheless it is always worth trying.

For the "traditional" load balancing service instead I reckon #1 is a very
good thing to discuss. Problem is that it is also hard to conclude anything
in 40 minutes. Async vs Synchronous has been discussed several times at the
summit; those sessions were really not very productive. Maybe if the
discussion is started early on the mailing list and supported with PoC code
it will be possible to scope the summit session in the right way.

#2 is not a LBaaS problem. It's a Neutron-wide problem. Async or
synchronous communication patterns also have a bearing on it. This is not
the first time this problem comes up. I think it might deserve a Neutron
session, but again starting the discussion on the mailing list will help to
ensure a productive outcome (and who knows we might even not need a summit
session after all!)

As a side note, the format for the next summit has not yet been formalised.
So maybe it's a bit early to talk about sessions. On the other hand, it's
good to dump topics which are worth being discussed at the summit.

Salvatore


On 29 August 2014 06:49, Brandon Logan <brandon.logan at rackspace.com> wrote:

> 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
> >
>
> _______________________________________________
> 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/20140829/c86fce56/attachment.html>