<p dir="ltr">Agree with Mike 1000%.</p>
<p dir="ltr">This is something we should have done ages ago, and being agnostic is the correct way to get traction on this stuff. We'll be happy to help.</p>
<p dir="ltr">Thanks for championing this!</p>
<div class="gmail_quote">On Nov 10, 2014 11:37 AM, "Michael Chapman" <<a href="mailto:woppin@gmail.com">woppin@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Here's the etherpad from Friday: <a href="https://etherpad.openstack.org/p/kilo-summit-ops-opsprogram" target="_blank">https://etherpad.openstack.org/p/kilo-summit-ops-opsprogram</a></div><div><br></div>Jonothan: Your example of including log filters in oslo is extremely confusing. I am talking about something like this: <a href="https://github.com/OpenStratus/openstack-logstash/blob/master/agent.conf" target="_blank">https://github.com/OpenStratus/openstack-logstash/blob/master/agent.conf</a><div><br></div><div>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.<br><div><br></div><div>Same idea for nagios/sensu/zabbix/$other_tool</div></div><div><br></div><div>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.</div><div><div><br></div><div>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.</div><div><br></div><div>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. </div><div>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. </div><div>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.</div></div><div><br></div></div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div>