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