Open Stack

No fundamental disagreement with the aim, I just think that the “there shall be only one” is not viable in the operations space.

I would fully support approaches such as “there should be only one puppet manifest set” rather than “there should be only one configuration management solution for OpenStack”.  A plug in architecture does not work as well without a shared agreement on the top level tool.

The summit Ops meetups can allow these groups to form and the working groups structure is intended to be very open so that where there is a community forming, we can help structure the convergence and sharing.

Tim


From: matt [mailto:matt at nycresistor.com]
Sent: 10 November 2014 21:03
To: Tim Bell
Cc: Craig Tracey; Michael Chapman; openstack-operators
Subject: Re: [Openstack-operators] Proposal for an 'Operations' project

I think that's the fundamental cultural divide between ops and development.  In the dev world we have guys who get paid to contribute to the open source side of the equation in ops, we really don't.  and that's pretty damned problematic for anyone attempting to maintain an openstack environment.  It tends to result in the creation of lots of technical debt rather than load sharing between different compatible entities.
I like the idea of promoting a cultural shift there, and I think if some lead the way others might follow and to great effect for the openstack community at large.
I can see why people want to spin up something in the vein of an operations tracked openstack project.  And I support the idea of plugging into the existing development and contribution workflows.  But maybe that means taking a page from the hypervisors and neutron plugins and moving to something like cloud foundry.  I don't know what the solution is.
Maybe for now there is not one.
-Matt

On Mon, Nov 10, 2014 at 2:52 PM, Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>> wrote:
So, how about maintaining a set of pointers to the github repos where we are all working ?

We publish and maintain http://github.com/cernops 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.

As an example, https://github.com/cernops/openstack-image-tools 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.

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.

Tim

From: matt [mailto:matt at nycresistor.com<mailto:matt at nycresistor.com>]
Sent: 10 November 2014 19:25
To: Tim Bell
Cc: Craig Tracey; Michael Chapman; openstack-operators

Subject: Re: [Openstack-operators] Proposal for an 'Operations' project

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.
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.

On Mon, Nov 10, 2014 at 1:03 PM, Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>> wrote:

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).

I think the github repo (https://github.com/osops) 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.

Unless everyone adopts Puppet, ElasticSearch, Hadoop and Flume like CERN ☺

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…

Tim

From: Craig Tracey [mailto:craig at craigtracey.com<mailto:craig at craigtracey.com>]
Sent: 10 November 2014 18:41
To: Michael Chapman
Cc: openstack-operators
Subject: Re: [Openstack-operators] Proposal for an 'Operations' project


Agree with Mike 1000%.

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.

Thanks for championing this!
On Nov 10, 2014 11:37 AM, "Michael Chapman" <woppin at gmail.com<mailto:woppin at gmail.com>> wrote:
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.


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141110/b07a38a8/attachment-0001.html>