Open Stack

Excerpts from Jay Pipes's message of 2016-02-17 13:25:58 -0500:
> On 02/17/2016 09:28 AM, Doug Hellmann wrote:
> > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +0000:
> >> A reason _I_[1] think we need to limit things is because from the
> >> outside OpenStack doesn't really look like anything that you can put
> >> a short description on. It's more murky than that and it is hard to
> >> experience positive progress in a fog. Many people react to this fog
> >> by focusing on their specific project rather than OpenStack at
> >> large: At least there they can see their impact.
> >
> > I've never understood this argument. OpenStack is a community
> > creating a collection of tools for building clouds. Each part
> > implements a different set of features, and you only need the parts
> > for the features you want.  In that respect, it's no different from
> > a Linux distro. You need a few core pieces (kernel, init, etc.),
> > and you install the other parts based on your use case (hardware
> > drivers, $SHELL, $GUI, etc.).
> 
> Yes. This.
> 
> > Are people confused about what OpenStack is because they're looking
> > for a single turn-key system from a vendor? Because they don't know
> > what features they want/need? Or are we just doing a bad job of
> > communicating the product vs. kit nature of the project?
> 
> I think we are doing a bad job of communicating the product vs. kit 
> nature of OpenStack.

Yeah, I tend to think that's it, too.

> 
> >> This results in increasing the fog because cross-project concerns (which
> >> help unify the vision and actuality that is OpenStack) get less
> >> attention and the cycle deepens.
> >
> > I'm not sure cross-project issues are really any worse today than
> > when I started working on OpenStack a few years ago. In fact, I think
> > they're significantly better.
> >
> > At the time, there were only the integrated projects and no real
> > notion that we would add a lot of new ones. We still had a hard
> > time recruiting folks to participate in release management, docs,
> > Oslo, infra, etc. The larger community and liaison system has
> > improved the situation. There's more work, because there are more
> > projects, but by restructuring the relationship of the vertical and
> > horizontal teams to require project teams to participate explicitly
> > we've reduced some of the pressure on the teams doing the coordination.
> >
> > Architecturally and technically, project teams have always wanted
> > to go their own way to some degree. Experimentation with different
> > approaches and tools to address similar problems like that is good,
> > and success has resulted in the adoption of more common tools like
> > third-party WSGI frameworks, test tools, and patterns like the specs
> > review process and multiple teams managing non-client libraries.
> > So on a technical front we're doing better than the days where we
> > all just copied code out of nova and modified it for our own purposes
> > without looking back.
> >
> > We also have several new cross-project "policy" initiatives like
> > the API working group, the new naming standards thing, and cross-project
> > spec liaisons. These teams are a new, more structured way to
> > collaborate to solve some of the issues we dealt with in the early
> > days through force of personality, or by leaving it up to whoever
> > was doing the implementation.  All of those efforts are seeing more
> > success because people showed up to collaborate and reach consensus,
> > and stuck through the hard parts of actually documenting the decision
> > and then doing the work agreed to. Again, we could always use more
> > help, but I see the trend as improving.
> >
> > We've had to change our approaches to dealing with the growth,
> > and we still have a ways to go (much of it uphill), but I'm not
> > prepared to say that we've failed to meet the challenge.
> 
> Agreed on your points above, Doug.
> 
> -jay
>