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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
