Open Stack

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141110/86f60884/attachment.html>