Open Stack

Could you please explain exactly what the Deployment Program is?  Is that
just the same as the Infra or TripleO project?  I confess that I do not
know what it is and until now haven¹t heard of it.

Is the main concern here around duplication of effort between the
Deployment Program and this proposed operators project?  I don¹t
understand if/why there is a problem with starting up an operators
project, other than semantics.

Mike

On 11/9/14, 9:45 AM, "Clint Byrum" <clint at fewbar.com> wrote:

>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.
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators