<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 10, 2014 at 2:52 PM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">So, how about maintaining a set of pointers to the github repos where we are all working ?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p></div></div></blockquote><div><br></div><div>I think this is more unsustainable than the osops repo itself. Rather than having the relevant things in one place, there's now a set of pointers to github repos that may have relevant nuggets of goodness in it surrounded by 10 times more irrelevant things. I think the point here was to create a coherent set of tools and configs that can be easily consumed and that you can count on to be reasonably current. We're trying to make things easier to find, not more difficult. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">We publish and maintain
<a href="http://github.com/cernops" target="_blank">http://github.com/cernops</a> in the open. This is for anything that is CERN specific or has a sustainability level such that we would not automatically recommend it to others. If it is of interest to everyone, we submit
it back to the community.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> </span></p></div></div></blockquote><div>You guys do fantastic work and it's wonderful that you do all of your work in the open. However, this one project of goodness is surrounded by forked puppet modules and things that are really only relevant to your specific environment or haven't been updated in 9+ months. It is difficult to figure out which things might be relevant to my use case. Your repo represents 50+ items to look through, and what you're talking about is having a list of 10, 100, 1000 such things to look through. It seems to me to lack the focus we're seeking.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">As an example,
<a href="https://github.com/cernops/openstack-image-tools" target="_blank">https://github.com/cernops/openstack-image-tools</a> shows the patches we’re doing for building images. Anyone can use this to build their tools but we are not proposing these as the ‘only’ solution
as a project would imply.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p></div></div></blockquote><div><br></div><div>I don't think anyone is proposing to have one thing be the defacto standard that everyone must follow. Imagine yours being a part of a well-described library of potential templates. You might be the maintainer of this one template that fits a particular use case. Now imagine that I could simply go into <a href="http://github.com/osops/disk-image-builder-templates">github.com/osops/disk-image-builder-templates</a> and there would be your stuff beside a number of other nice samples with good documentation that people could choose to consume or modify for their own purposes without having to have dug through 1000 other projects to find.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">For me, there is a need for code publication without commitment to support. Asking operators to commit to support outside of their
‘day-jobs’ where the return on investment (i.e. high quality contributions and enhancements back) has not been proven is a lot to ask.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p></div></div></blockquote><div><br></div><div>I think the number of folks that showed up to an impromptu session at 9am on a Friday morning after the Ops summit was already over expressing a willingness to contribute pretty much said that we have enough willingness among operators to contribute. I honestly don't think it would take that much time from our day jobs so long as the parts are broken down into manageable chunks and are assigned to people who already are writing these configs to begin with. The initial setup will be somewhat time-consuming, but the ongoing maintenance will be less so. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Tim<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> matt [mailto:<a href="mailto:matt@nycresistor.com" target="_blank">matt@nycresistor.com</a>]
<br>
<b>Sent:</b> 10 November 2014 19:25<br>
<b>To:</b> Tim Bell<br>
<b>Cc:</b> Craig Tracey; Michael Chapman; openstack-operators</span></p><div><div class="h5"><br>
<b>Subject:</b> Re: [Openstack-operators] Proposal for an 'Operations' project<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">My fear with the github is that people will just donate code in a fire and forget fashion... this will generate a poorly maintained repo in which finding useful actively maintained contributions may become difficult.<u></u><u></u></p>
</div>
<p class="MsoNormal">So my concerns lie in ensuring that anyone who contributes to this effort is committing to supporting their code for some length of time, and that there are maintainers committing to cleaning out the repos and being good code janitors.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Nov 10, 2014 at 1:03 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">My impression of the operations teams is that there is not yet consensus on the toolchains. This would
make it difficult to establish a single project since the selection has many criteria outside of OpenStack (e.g. in-house skills, current deployments).</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I think the github repo (<a href="https://github.com/osops" target="_blank">https://github.com/osops</a>)
is a great move to allow easy access to how others are doing it but it would be unrealistic to expect everyone to adopt a single toolchain given the investment in other areas.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Unless everyone adopts Puppet, ElasticSearch, Hadoop and Flume like CERN
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The deployment program is very different and it is not clear to me that TripleO is the universal solution
either but that is another question…</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Tim</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Craig
Tracey [mailto:<a href="mailto:craig@craigtracey.com" target="_blank">craig@craigtracey.com</a>]
<br>
<b>Sent:</b> 10 November 2014 18:41<br>
<b>To:</b> Michael Chapman<br>
<b>Cc:</b> openstack-operators<br>
<b>Subject:</b> Re: [Openstack-operators] Proposal for an 'Operations' project</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p>Agree with Mike 1000%.<u></u><u></u></p>
<p>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.<u></u><u></u></p>
<p>Thanks for championing this!<u></u><u></u></p>
<div>
<p class="MsoNormal">On Nov 10, 2014 11:37 AM, "Michael Chapman" <<a href="mailto:woppin@gmail.com" target="_blank">woppin@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">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><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">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><u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Same idea for nagios/sensu/zabbix/$other_tool<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">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><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">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><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</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><br></div><div class="gmail_extra">-Erik</div></div>