Frank, I'd echo Hang Liu's suggestion, but also encourage you to take this
question to the general OpenStack mailing
list (see https://wiki.openstack.org/wiki/Mailing_Lists).
- Phil
From: Hang H Liu [mailto:hang...@cn.ibm.com]
Sent: Wednesday, November 05, 2014 7:36 AM
To: OpenStack
From: Dina Belova [mailto:dbel...@mirantis.com]
On Friday, October 03, 2014 2:53 AM
Igor,
Personally this idea looks really nice to me, as this will help to avoid
strange code being merged and not found via reviewing process.
Cheers,
Dina
On Fri, Oct 3, 2014 at 12:40 PM, Igor
On 9/04/2014 Sandy Walsh wrote:
Yesterday, we had a great conversation with Matt Rutkowski from IBM,
one
of the authors of the CADF spec.
I was having a disconnect on what CADF offers and got it clarified.
My assumption was CADF was a set of transformation/extraction rules
for
taking
cases. Will work
OVERCLOUD_USE_CEILOMETER use case into changes first, then address UI later if
someone else hasn't picked it up.
- Phil
On 04/22/2014 06:23 PM, Neal, Phil wrote:
From: Ladislav Smola [mailto:lsm...@redhat.com]
Sent: Wednesday, April 16, 2014 8:37 AM
To: openstack-dev
From: Ladislav Smola [mailto:lsm...@redhat.com]
Sent: Wednesday, April 16, 2014 8:37 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] [Tuskar] Undercloud Ceilometer
No response so far, but -1 on the image element for making Ceilometer
optional.
Sorry for the
-Original Message-
From: Tim Bell [mailto:tim.b...@cern.ch]
Sent: Monday, March 17, 2014 2:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] [QA] Slow Ceilometer
resource_list CLI command
At CERN, we've had similar
For multi-node deployments, implementing something like inotify would allow
administrators to push configuration changes out to multiple targets using
puppet/chef/etc. and have the daemons pick it up without restart. Thumbs up to
that.
As Tim Bell suggested, API-based enabling/disabling would
+1. Sandy has been both helpful and insightful, plus he happens to have a good
handle on the many moving parts that make up this project. :-)
-Phil
-Original Message-
From: Lu, Lianhao [mailto:lianhao...@intel.com]
Sent: Sunday, December 15, 2013 5:29 PM
To: OpenStack Development
Sean, we currently have a BP out there to investigate basic tempest
integration and I think this might fall under the same umbrella.
Unfortunately I've not been able to free up my development time
for it, but I've assigned it out to someone who can take a look and
report back.
-Original Message-
From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
Sent: Thursday, October 10, 2013 6:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] Notifications from non-local
exchanges
On 10/10/2013 06:16 PM, Neal, Phil wrote
Greetings all,
I'm looking at how to expand the ability of our CM instance to consume
notifications and have a quick question about the configuration and flow...
For the notifications central agent , we rely on the services (i.e. glance,
cinder) to drop messages on the same messaging host as
Greetings team,
I'm working on getting a very streamlined set of collections running and I'd
like to disable all notifications except Glance. It's clear that the desired
event types are defined in the plugins, but I can't seem to work out how to
force the collector service to load only specific
-Original Message-
From: Eoghan Glynn [mailto:egl...@redhat.com]
Sent: Thursday, July 04, 2013 3:36 AM
To: OpenStack Development Mailing List; Neal, Phil
Subject: Re: [openstack-dev] [Ceilometer] Changing pollster/pipeline
parameters
Hi Phil,
Some more thoughts inline
A couple of related questions on managing CM pollster behavior via config
type files:
1. I'm trying to make some modifications to the timing of the Glance (image)
polling in a default CM install. It looks like the pipeline interval fields are
the way to do it, and that I should tweak it using
14 matches
Mail list logo
