Open Stack

On 09/03/2014 11:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
> 
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> Have anyone interested (especially TC members) come up with a list of
> what they think the project wide Kilo cycle goals should be and post
> them on this thread by end of day Wednesday, September 10th. After which
> time we can begin discussing the results.
> The goal of this exercise is to help us see if our individual world
> views align with the greater community, and to get the ball rolling on a
> larger discussion of where as a project we should be focusing more time.

In OpenStack, we have no shortage of interest and enthusiasm on all
fronts, including development contributors, deployers, and cloud end
users.  When looking at project wide-priorities, we need to make sure
our tools, processes, and resulting technology facilitate turning all of
that interest into real value.  We need to identify which areas have the
most pain, and work to improve them.

A lot of this is certainly about Kilo, but it's longer term, too.  It's
the way we should always be thinking about this.

1) Dev community

We clearly have a lot of growing pains here.  What's quite encouraging
is that we also have a lot of hard work going into several different
proposals to figure out ways to help.

The largest projects (Nova and Neutron) are overwhelmed and approaching
breaking points.  We have to find ways to relieve this pressure.  This
may involve aggressively pursing project splits or other code review
workflow changes.  I think the problems and solutions here are
project-wide issues, as solutions put in place tend to rapidly spread to
the rest of OpenStack.  This is an area I'm especially concerned about
and eager to help look for solutions.  We should evaluate all potential
improvements against how well they help us scale our teams and processes
to remove bottlenecks to productivity in the dev communtiy.

There are several other encouraging proposals related to easing pain in
the dev community:

 - re-working how we do functional testing by making it more project focused

 - discussions like this one to discuss both priorities, but also how we
turn priorities into real action (like the nova projects discussions
around using priorities in development)

 - evolving project leadership (the PTL position) so that we can provide
more guidance around delegation in a way that is reasonably consistent
across projects

 - continued discussion about the contents of the integrated release and
how we can continue to foster growth without sacrificing quality

We are always going to have problems like this, and I hope we continue
to think about, discuss, and improve the way we run our projects every
release cycle to come.

2) End Users

A few others have done a very nice job describing end user experience
problems.  Monty's description of getting an instance with an IP was
painful and embarrassing to read.  We've got to figure out ways to
provide better focus on these sorts of usability issues.  They're
obviously not getting the attention they deserve.

There have also been lots of good points about improving our API
consistency.  I totally agree.  I'd love to see a group of people step
up and emerge as leaders in this area across all projects.  I feel like
that's something we're sorely missing right now.

3) Deployers

OpenStack is still painful to deploy, and even more painful to manage.
  I'm still quite pleased that we have a deployment program working on
this space.  I'd actually really like to see how we can facilitate
better integration and discussion between TripleO and the rest of the
project teams.

I'm also very pleased with the progress we've made in Nova towards the
initial support for live upgrades.  We still have more work to do in
Nova, but I'd also like to see more work done in other projects towards
the same goal.

For both deployers and the dev community, figuring out what went wrong
when OpenStack breaks sucks.  Others provided some good pointers to
several areas we can improve that area (better logs, tooling, ...) and I
hope we can make some real progress in this area in the coming cycle.

-- 
Russell Bryant