[Openstack-operators] Proposal for an 'Operations' project

Clint Byrum clint at fewbar.com
Mon Nov 10 16:21:55 UTC 2014

Excerpts from Michael Chapman's message of 2014-11-10 02:33:33 -0800:
> Here's the etherpad from Friday:
> https://etherpad.openstack.org/p/kilo-summit-ops-opsprogram
> Jonothan: Your example of including log filters in oslo is extremely
> confusing. I am talking about something like this:
> https://github.com/OpenStratus/openstack-logstash/blob/master/agent.conf
> Which really doesn't belong in oslo. There's similar configuration for
> equivalents such as splunk or fluentd, all doing roughly the same thing
> depending on the operator's tool of choice.
> Same idea for nagios/sensu/zabbix/$other_tool
> Jeremy: OpenStack is so large that setting up packaging, monitoring and log
> aggregation for it isn't something that can be done easily, yet without
> configuring any monitoring or log aggregation it is extremely difficult to
> diagnose and fix issues in a running cloud, and without a packaging
> pipeline fixes can't be deployed easily.
> As to whether to include these things in the deployment program, I would
> say that I think the Deployment program is covering a 'delivery mechanism',
> whereas the things I am talking about are 'things to be delivered'. Clint
> and I had a quick chat on Friday during the TripleO session and I think we
> are thinking along very similar lines.

Indeed we are. The Deployment program is more than just a delivery
mechanism, but also an operations mechanism. We don't want to deliver
an unrealistic system. But we are emphatically going to make sure that
we define good interfaces to allow other tools to be substituted on
either side. The thinking would be that users who have proven
configurations of various support systems can collaborate in an ops
project, and as long as they implement the configuration interfaces that
we define together, they can be swapped in and still take advantage of
the deployment program's work.

Likewise, if somebody has a deployment model that they want to use other
than the one we've been building, they can write to those interfaces
and get the benefits of the work of others.

> I want to have a bunch of repos with things that deployment tools
> (including Fuel and TripleO and anything else that gets cooked up) can
> easily consume to improve the operator experience.
> I want a standard packaging system so that sites doing CI/CD today can all
> build packages from their own repos and collaborate on the specs/process in
> an upstream location, and I want it to be easily clone-able locally.
> I want it all under a single program so that in the future we can
> potentially reward and acknowledge people doing the work as contributors to
> OpenStack.

Indeed. I think TripleO can scale to more contributors, but it seems to
me you have defined a clear point of collaboration that can be beneficial
to the community independent of TripleO.

More information about the OpenStack-operators mailing list