Open Stack

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.

>> 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