Open Stack

Excerpts from Jeremy Stanley's message of 2014-11-08 16:23:02 -0800:
> On 2014-11-08 04:08:08 -0500 (-0500), Fischer, Matt wrote:
> [...]
> > Perhaps some of the code fits in some places as previously
> > mentioned on the list, but the issue is that none of those
> > projects really focus on operations. The projects are inevitably
> > developer focused, despite the best attempts to get operator
> > feedback.
> [...]
> 
> I would counter that we have lots of operator-focused projects
> already underway... the Infra and QA teams, for example, have plenty
> of projects which are entirely shell scripts and configuration
> management. If you were in any of the Deployment Program's design
> sessions, there was a fairly consistent message that Triple-O is
> encouraging direct involvement from the various config management
> teams to bring more officialness to the diverse tools with which
> OpenStack is deployed and managed at production sites.
> 
> If the projects you want to start aren't focused on deployment and
> lifecycle management, nor on community infrastructure tools, nor on
> documentation, then I would buy that there's some potential project
> use cases for which we haven't made suitable homes yet. But I'd hate
> to see that used to further what I see as an unnecessary separation
> between "developers" and "operators."

There's this crazy movement underway called "DevOps" where we stop
treating these two groups as independent victims of each-other's
conflicting responsibilities. Instead we need to see each as simply _more_
focused on one responsibility or another, but all on the same team with
the same end goal of a stable, agile deployment.

Given that most of us seem to believe that, I am really confused
why anybody sees the Deployment Program as anything other than an
operations focused project. It is entirely focused on deploying and
operating OpenStack. The fact that we've stated we will use components
of OpenStack whenever that is possible is secondary to the first charge
of actually deploying a managable OpenStack cloud.

Now I understand, in the past we have been entirely prescriptive and
opinionated on levels that have made large portions of the operators
feel excluded. That may have been necessary to make some early progress,
but I don't believe it will continue.

I sat with several people who attended the gathering of operators that
this thread references, and at least the few of us there agreed that most
of what they discussed wasn't specifically about deploying OpenStack,
but about deploying it with all of the supporting tools that surround
OpenStack. This sounds like the beginnings of a complimentary program.

I am quite excited to see some discussion around coalescing these
efforts. Having diverse deployments is useful for finding efficient ways
to solve real problems. How you get logs into LogStash and what Kibana
queries you use to find issues is interesting. Whether you express that
you want your logs in LogStash as Chef, Puppet, or diskimage-builder
elements with os-apply-config templates and os-refresh-config scripts
is pretty uninteresting in comparison.