and show the
convergence opportunity.
Tim
From: Erik McCormick [mailto:emccorm...@cirrusseven.com]
Sent: 10 November 2014 21:16
To: Tim Bell
Cc: matt; openstack-operators
Subject: Re: [Openstack-operators] Proposal for an 'Operations' project
On Mon, Nov 10, 2014 at 2:52 PM, Tim Bell
ma
SNIP
Examples of existing repositories which I suspect won't be copied to
osops repository:
* https://github.com/krislindgren/openstack-logstash/tree/master
Actually, that one has been in the osops repo for a few months. Mike Dorman put
it there.
But, to be fair, I am also worried about fire a
att [mailto:m...@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 w
convergence and sharing.
Tim
From: matt [mailto:m...@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 div
>
> I fear that people contributing scripts to osops/* will forget about them
> and scripts will go stalled over time.
>
That's a fair assessment and that's probably what will happen to a lot of
the items added to those repositories. But really any open source project
is susceptible to that.
Both
lto:m...@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
[mailto:m...@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...
On 2014-11-10 1:24 PM, matt wrote:
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 w
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:cr...@craigtracey.com]
> *Sent:* 10 November 2014 18:41
> *To:* Michael Chapman
> *Cc:* openstack-
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:cr...@craigtracey.com]
Sent: 10 November 2014 18:41
To: Michael Chapman
Cc: openstack-operators
Subject: Re: [Openstack-operators] Proposal for an
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" wrote:
> Here's the etherpad from Friday:
> https://etherp
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:
> htt
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 reall
Could you please explain exactly what the Deployment Program is? Is that
just the same as the Infra or TripleO project? I confess that I do not
know what it is and until now haven¹t heard of it.
Is the main concern here around duplication of effort between the
Deployment Program and this propose
Excerpts from Jeremy Stanley's message of 2014-11-08 16:23:02 -0800:
> On 2014-11-08 04:08:08 -0500 (-0500), Fischer, Matt wrote:
> [...]
> > Perhaps some of the code fits in some places as previously
> > mentioned on the list, but the issue is that none of those
> > projects really focus on operat
I would wager to say that all operators also develop on OpenStack to some
degree. You have to at this point in the maturity of OpenStack. They may
not all be fixing bugs upstream, but they are certainly getting their
hands dirty with the code. So I don't think there is group of people that
are p
On 2014-11-08 04:08:08 -0500 (-0500), Fischer, Matt wrote:
[...]
> Perhaps some of the code fits in some places as previously
> mentioned on the list, but the issue is that none of those
> projects really focus on operations. The projects are inevitably
> developer focused, despite the best attempt
+1000 to what Matt said.
Another point worth considering is that "operations"-type projects are
often in a fast-follow mode. All of areas of interest (logging, packaging,
monitoring, etc.) are effectively out of band from anything OpenStack
proper. We should be able to release these at our own c
On 11/8/14, 9:10 AM, "Jeremy Stanley" wrote:
>On 2014-11-07 22:25:49 +0100 (+0100), Jonathan Proulx wrote:
>[...]
>> An "Ops Project" feels weird to me.
>[...]
>
>To me as well. Perhaps this is the "operator community" coming to
>the realization that they don't need to be separate from the
>"deve
On 2014-11-07 22:25:49 +0100 (+0100), Jonathan Proulx wrote:
[...]
> An "Ops Project" feels weird to me.
[...]
To me as well. Perhaps this is the "operator community" coming to
the realization that they don't need to be separate from the
"developer community." I've never really quite understood th
Sorry to have missed the lobby discussion on this this morning.
An "Ops Project" feels weird to me.
Most things I can think of going into this space seem to be better
served as part of existing projects. For one example logging filters
& parsers should probably be distributed with Oslo which def
On 07/11/14 01:42, Michael Dorman wrote:
> This same thing came up at the mid-cycle Ops meet up at RAX in August.
> There wasn’t much action that came from it, but we did set up a new
> org in GitHub for collecting this type of common stuff:
> https://github.com/osops
>
Excellent! Wish I'd notice
Yes! I would like these things to live under a official openstack program
so there is a clear collaboration point. This should not be stack forge it
should be openstack and we should aim for incubation and recognition of
contributions.
On 06/11/2014 1:42 PM, "David Moreau Simard" wrote:
> As far
On 6 November 2014 at 12:30:00, Michael Chapman (wop...@gmail.com) wrote:
Hi Operators!
I felt like OpenStack didn't have enough projects, so here's another one.
During the summit I feel like I'm repeatedly having the same conversations with
different groups about bespoke approaches to operati
It's likely premature for it to have shown up under OpenStack, but that's for a
different thread!
> On Nov 6, 2014, at 16:33, Clint Byrum wrote:
>
> Except in the case of TripleO which is available as an official
> OpenStack project.
___
OpenStack-o
openstack-operators-requ...@lists.openstack.org wrote:
Hi Operators!
I felt like OpenStack didn't have enough projects, so here's another one.
During the summit I feel like I'm repeatedly having the same conversations
with different groups about bespoke approaches to operational tasks, and
wrap
Excerpts from Michael Chapman's message of 2014-11-06 12:20:52 +0100:
> Hi Operators!
>
> I felt like OpenStack didn't have enough projects, so here's another one.
>
> During the summit I feel like I'm repeatedly having the same conversations
> with different groups about bespoke approaches to op
As far as monitoring is concerned, we've just had a session at the Ops summit -
etherpad: https://etherpad.openstack.org/p/kilo-summit-ops-monitoring
Definitely lots of various initiatives regarding monitoring scripts/tools that
could benefit from being centralized.. at a quick glance:
- https:/
enstack-operators] Proposal for an 'Operations' project
Hi Operators!
I felt like OpenStack didn't have enough projects, so here's another one.
During the summit I feel like I'm repeatedly having the same conversations with
different groups about bespoke approaches to o
Earlier today Jay Pipes mentioned that he had some rsyslog config examples for
Doing Useful Things with openstack logs. This would be another useful place to
store such things.
Another thing worth tracking would be one off ops-task tooling. Those little
shell scripts we've all written to true u
Hi Operators!
I felt like OpenStack didn't have enough projects, so here's another one.
During the summit I feel like I'm repeatedly having the same conversations
with different groups about bespoke approaches to operational tasks, and
wrapping these in a project might be a way to promote collabo
31 matches
Mail list logo
