On 10/03/14 05:15 -0400, Eoghan Glynn wrote:
Folks,
Time for some new blood on the ceilometer core team.
I'd like to nominate Ildikó Váncsa and Nadya Privalova as ceilometer
cores in recognition of their contributions([1], [2]) over the Icehouse
cycle, and looking forward to their continued
On Mon, Mar 10, 2014 at 5:15 AM, Eoghan Glynn egl...@redhat.com wrote:
Folks,
Time for some new blood on the ceilometer core team.
I'd like to nominate Ildikó Váncsa and Nadya Privalova as ceilometer
cores in recognition of their contributions([1], [2]) over the Icehouse
cycle, and
I'd like to nominate Ildikó Váncsa and Nadya Privalova as ceilometer
+1, thanks for the effort so far.
cheers,
gordon chung
openstack, ibm software standards___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On Fri, Mar 07 2014, Yuuichi Fujioka wrote:
Hi,
We would like to request FFE for monitoring-network-from-opendaylight.[1][2]
Unfortunately, it was not merged by Icehouse-3.
This is the first driver of the bp/monitoring-network.(It was merged)[3]
We strongly believe this feature will enhance
On 03/07/2014 07:22 AM, Julien Danjou wrote:
On Fri, Mar 07 2014, Yuuichi Fujioka wrote:
Hi,
We would like to request FFE for monitoring-network-from-opendaylight.[1][2]
Unfortunately, it was not merged by Icehouse-3.
This is the first driver of the bp/monitoring-network.(It was
On Fri, Mar 07 2014, Sean Dague wrote:
Are the reviews already posted?
Yes.
And are there 2 ceilometer core members signed up for review (names
please)?
I can be one, and I'm sure Lianhao Lu and Gordon Chung will continue to
look at it.
Are we sure this is mergable by Tuesday - pre
Chung [mailto:chu...@ca.ibm.com]
Sent: Wednesday, March 05, 2014 6:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Suggestions for alarm improvements
hi Sampath
tbh, i actually like the pipeline solution proposed
thank you very much
seems I should search the launchpad more carefully
On Thu, Mar 6, 2014 at 3:37 PM, Mehdi Abaakouk sil...@sileht.net wrote:
Hi,
On Thu, Mar 06, 2014 at 10:44:25AM +0800, ZhiQiang Fan wrote:
I already check the stable/havana and master branch via devstack, the
problem
Hello, Sampth.
My interest lies in how to evaluate large number of notifications within a
short time.
I thought moving alarms into the pipelines would be a good start.
How about evaluate Synaps for your use case? It evaluates alarms in the storm
topology(pipeline). Moving alarms into the
Hi,
We would like to request FFE for monitoring-network-from-opendaylight.[1][2]
Unfortunately, it was not merged by Icehouse-3.
This is the first driver of the bp/monitoring-network.(It was merged)[3]
We strongly believe this feature will enhance ceilometer's value.
Because many people are
I already check the stable/havana and master branch via devstack, the
problem is still in havana, but master branch is not affected
I think it is important to fix it for havana too, since some high level
application may depends on the returned faultstring. Currently, I'm not
sure mater branch fix
Hi,
On Thu, Mar 06, 2014 at 10:44:25AM +0800, ZhiQiang Fan wrote:
I already check the stable/havana and master branch via devstack, the
problem is still in havana, but master branch is not affected
I think it is important to fix it for havana too, since some high level
application may
Hi All,
Sandy did a great job by putting up some valuable points for alarm
improvements in,
https://wiki.openstack.org/wiki/Ceilometer/AlarmImprovements
Is there any further discussion about [Part 4 - Moving Alarms into the
Pipelines] in above doc?
I tried to find more info about above topic
Hi,
Le jeudi 27 février 2014, à 09:12 +0800, ZhiQiang Fan a écrit :
thanks, Vincent
I already noticed that the critical bug is caused by a wrong backport, just
in the
Hi,
Le mercredi 26 février 2014, à 17:20 +0800, ZhiQiang Fan a écrit :
Hi, SUSE OpenStack developers,
After install OpenStack Havana on SLES 11 SP3 following the
openstack-manuals' guide, I find that the
ceilometer/storage/impl_sqlalchemy.py has implemented the metaquey
functionality.
thanks, Vincent
I already noticed that the critical bug is caused by a wrong backport, just
in the
0001-enable-sql-metadata-query.patchhttps://build.opensuse.org/package/view_file/Cloud:OpenStack:Havana/openstack-ceilometer/0001-enable-sql-metadata-query.patch?expand=1line
124, session.flush()
Hi Liusheng,
We are having the same performance issues and interested in
the following bug ticket.
https://bugs.launchpad.net/ceilometer/+bug/1264434
You said,
As you said.both the schema level and the code level,the SQL driver in
Ceilometer should be optimized. thanks for your advicese.I
Hi,
When I try to figure out the root cause of bug[1], I found that once
wsme.exc.ClientSideError is triggerd when create an alarm, assume the
faultstring is x, then if next http trigger a EntityNotFound(Exception)
will get http response with faultstring equal to x.
I trace the calling stack
On Sat, Feb 15, at 4:41 am, Akhil Sadashiv Hingane wrote:
When I try to run the test cases for ceilometer, it fails with
Traceback (most recent call last):
File /usr/local/bin/tox, line 9,
On Sat, Feb 15, 2014 at 6:45 AM, Henry Gessau ges...@cisco.com wrote:
On Sat, Feb 15, at 4:41 am, Akhil Sadashiv Hingane wrote:
When I try to run the test cases for ceilometer, it fails with
On Mon, Feb 10 2014, ZhiQiang Fan wrote:
So, is this loose policy limit designed purposely, or it just a simple
implementation for policy?
It's just nobody stepped up to implement a more complete one, indeed.
So, is there any opportunity to implement more strict policy check, for
i.e. a
Hi,
I noticed that the Ceilometer project has no strict policy control, the
/etc/ceilometer/policy.json only has one single rule 'context_is_admin',
and for each specific resource operation, it will invoke acl.get_limit_to
and v2._verify_query_segregation to forbid non-admin role operate other
On 31/01/14 21:50, Julien Danjou wrote:
On Fri, Jan 31 2014, Adrian Turjak wrote:
Is it working on Havana? As I've gone through and tried all the possible
state changes (reboot, suspend, pause, resize, terminate, etc), and not one
triggers a poll cycle outside of the standard polling
On Tue, Jan 28, 2014 at 6:49 PM, Ladislav Smola lsm...@redhat.com wrote:
Might be good to monitor it via SNMPD. As this daemon will be
already running on each node. And I see it should be possible, though
not very popular.
Then it would be nice to have the data stored in Ceilometer, as
it
On Thu, Jan 30 2014, Adrian Turjak wrote:
example:
10min pipeline interval, a reset/shutdown happens 7 mins after the last
poll. The data for those 7 mins is gone. Even terminating a VM will mean we
lose the data in that last interval.
If the shutdown is down properly, the nova notifier
On 30/01/2014 23:31, Julien Danjou wrote:
On the other hand, would it be possible to setup a notification based metric
that updates cumulative metrics, or triggers a poll right before the
reset/shutdown/suspension/terminate, so we have an entry right before it
resets and don't lose any data?
On Thu, Jan 30 2014, Adrian Turjak wrote:
Awesome! But where in the source are they? As the only two notification
plugins that seem to exist on the compute agent are for cpu and instance. Is
there meant to be one that handles network.outgoing/incoming updates on
those VM state changes?
This
A question about this bug:
https://bugs.launchpad.net/ceilometer/+bug/1061817
In the billing program we are currently writing we've partly accounted
for resetting of values in a given period for the cumulative metrics,
but since we need high accuracy especially for metrics like
On Mon, Jan 27 2014, Adrian Turjak wrote:
Is there a way to transform data once it reaches the collector?
No, but that would probably be the easiest way.
The other alternative is to compute it via the API.
--
Julien Danjou
-- Free Software hacker - independent consultant
--
Excerpts from Richard Su's message of 2014-01-27 17:59:34 -0800:
Hi,
I have been looking into how to add process/service monitoring to
tripleo. Here I want to be able to detect when an openstack dependent
component that is deployed on an instance has failed. And when a failure
has occurred
Hello,
excellent, this is exactly what we need in Tuskar. :-)
Might be good to monitor it via SNMPD. As this daemon will be
already running on each node. And I see it should be possible, though
not very popular.
Then it would be nice to have the data stored in Ceilometer, as
it provides
On 27/01/14 23:41, Julien Danjou wrote:
On Mon, Jan 27 2014, Adrian Turjak wrote:
I created a gauge metric that is updated via notifications, and a pollster.
The data from both of those needs to be transformed in to a cumulative
metric. The transformer object works as intended, but the issue
Hi,
I have been looking into how to add process/service monitoring to
tripleo. Here I want to be able to detect when an openstack dependent
component that is deployed on an instance has failed. And when a failure
has occurred I want to be notified and eventually see it in Tuskar.
Ceilometer
On 28 January 2014 14:59, Richard Su r...@redhat.com wrote:
Hi,
I have been looking into how to add process/service monitoring to
tripleo. Here I want to be able to detect when an openstack dependent
component that is deployed on an instance has failed. And when a failure
has occurred I want
Hello,
I've been trying to build a transformer, and while I've gotten it to
work as intended for the most part, I've run into a weird issue because
the metric I'm transforming has two inputs.
I created a gauge metric that is updated via notifications, and a
pollster. The data from both of
Hi Ceilometer guys,
We are implementing a complex query functionality for Ceilometer. We got a
comment to our implementation that using JSON in a string for representing the
query filter expression, is probably not the best solution.
The description of our current API design can be found here:
On Wed, Jan 22 2014, Matthieu Huin wrote:
Hi Matthieu,
I'd be interested in some opinions and feedback on the following blueprint:
https://blueprints.launchpad.net/ceilometer/+spec/quotas-on-alarms
Sounds like a good idea.
I think it'd be interesting to allow admins to limit the number of
Hello Julien,
- Original Message -
From: Julien Danjou jul...@danjou.info
To: Matthieu Huin matthieu.h...@enovance.com
Cc: openstack-dev openstack-dev@lists.openstack.org
Sent: Thursday, January 23, 2014 11:13:23 AM
Subject: Re: [openstack-dev] [ceilometer] per domain/project/user
On Thu, Jan 23 2014, Matthieu Huin wrote:
This doesn't seem like something that will be done:
http://lists.openstack.org/pipermail/openstack-dev/2013-December/020799.html
My understanding is that the favored approach would be to let each component
manage quotas on their own, with an eventual
Hi,
Updated the blueprint based on the suggestions from the community.
Mentioned high level call-flow.
Please go through it and let me know your views.
https://blueprints.launchpad.net/ceilometer/+spec/dynamic-meters
Regards,
VijayKumar Kodam
___
Greetings,
I'd be interested in some opinions and feedback on the following blueprint:
https://blueprints.launchpad.net/ceilometer/+spec/quotas-on-alarms
I think it'd be interesting to allow admins to limit the number of running
alarms at any of the three levels defined by keystone. Thoughts ?
Gordon Chung wrote on 2014-01-21:
If the resources defined in the pipeline doesn't match any resource
file loader, it will be treated as directly passing to the pollsters. E.g.
resources:
- fileloader:///foo/bar
- snmp://2.2.2.2
The endpoint 'snmp://2.2.2.2' will be
Hi CM guys,
jd__ wanted to hold off the patch https://review.openstack.org/58747 because he
thinks it's not generic enough and want to have a further discussion about the
resource loader support. So I put it here my original thought and design about
the patch as a start point.
The initial
5:10 AM
To: Gao, Fengqian
Cc: Julien Danjou (jul...@danjou.info); Doug Hellmann
(doug.hellm...@dreamhost.com); Lu, Lianhao; chu...@ca.ibm.com;
dper...@linux.vnet.ibm.com; akornie...@mirantis.com;
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev][ ceilometer] The Pagination
Fujioka [fujioka-yuui...@zx.mxh.nes.nec.co.jp]
Sent: Wednesday, December 11, 2013 8:25 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ceilometer] RFC: blueprint monitoring-network
Hi, Ceilometer team.
We have posted 2 blueprints.[1][2]
This feature collects the network
;
dper...@linux.vnet.ibm.com; akornie...@mirantis.com;
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev][ ceilometer] The Pagination patches
On Fri, 2014-01-10 at 03:31 +, Gao, Fengqian wrote:
Since we still have no new conclusion for pagination for now, shall we
still go
Hi,
When read Ceilometer install guide[1], the multi valued option
notification_driver is set to two drivers, My question is that is the first
one, which means nova.openstack.common.notifier.rpc_notifier, necessary?
what will happen if it is removed?
Note, it is not configured even in Nova
On Wed, Jan 15, 2014 at 1:32 PM, ZhiQiang Fan aji.zq...@gmail.com wrote:
Hi,
When read Ceilometer install guide[1], the multi valued option
notification_driver is set to two drivers, My question is that is the first
one, which means nova.openstack.common.notifier.rpc_notifier, necessary?
On Mon, 2014-01-13 at 13:39 +0400, Nadya Privalova wrote:
Jay,
Thanks for comments!
The question you raised was discussed several times within Ceilometer
team but as I understand there is no official resolution yet.
I agree with you that statistics' collection is the main
On Fri, 2014-01-10 at 03:31 +, Gao, Fengqian wrote:
Since we still have no new conclusion for pagination for now, shall we
still go on with the current pagination solution?
Please help to review patches:
https://review.openstack.org/#/c/41869/
https://review.openstack.org/#/c/35454/
On Fri, 2014-01-10 at 17:10 +0400, Nadya Privalova wrote:
Idea:
The goal is to improve performance when user gets statistics for
meter. Now we have fixed list of statistics (min, max and so on).
During request a user may specify the following params:
1. query
2. group_by
3. period
The
Hi team,
I've decided to move discussion about aggregation in mailing list.
Here is a description about my idea and I really need your comments.
*Idea:*
The goal is to improve performance when user gets statistics for meter. Now
we have fixed list of statistics (min, max and so on). During
From: ext Doug Hellmann [mailto:doug.hellm...@dreamhost.com]
Sent: Wednesday, January 08, 2014 10:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Wed, Jan 8, 2014 at 3:09 PM, Kodam, Vijayakumar
From: Yuuichi Fujioka [fujioka-yuui...@zx.mxh.nes.nec.co.jp]
Sent: Wednesday, December 11, 2013 8:25 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ceilometer] RFC: blueprint monitoring-network
Hi, Ceilometer team.
We have posted 2 blueprints.[1][2]
This feature
...@hp.com]
Sent: Tuesday, January 07, 2014 11:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
For multi-node deployments, implementing something like inotify would allow
administrators to push configuration
Hi,
Your result is interesting and not surprising due to the different design
you have described.
The Ceilo team will work on the improvements IIUC.
I found two relevant links [1] [2]
@jay : the first case seems to be impossible, no scalable .. I bet for the
last :)
@June li
I am curious to
with the initial design of
how this feature could work.
Best Regards,
Ildiko
-Original Message-
From: Neal, Phil [mailto:phil.n...@hp.com]
Sent: Tuesday, January 07, 2014 11:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer
Hi,
-Original Message-
From: ext Neal, Phil [mailto:phil.n...@hp.com]
Sent: Wednesday, January 08, 2014 12:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
For multi-node deployments
From: ext Tim Bell [mailto:tim.b...@cern.ch]
Sent: Tuesday, January 07, 2014 8:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
Thinking using inotify/configuration file changes to implement dynamic
On Wed, Jan 08 2014, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)
wrote:
According to the latest update:
User calls the API(1) to disable a meter along with a meter id.
What's an user? An end-user or an operator?
I don't think we want to allow a user to disable a meter. I don't
On Wed, Jan 08 2014, Ildikó Váncsa wrote:
(Your answers are very hard to read inline in my text MUA, it'd really
help if you could quote properly with the emails you answer to).
ildikov: Sorry, my explanation was not clear. I meant there the
configuration of data collection for projects, what
(not for usage questions)
*Subject:* Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa ildiko.van...@ericsson.com
wrote:
Hi,
I've started to work on the idea of supporting a kind of tenant/project
based configuration
)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
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
Hi,
(You didn't Cc the list, not sure if it was on purpose. I'm not adding it back
to not break any confidentiality, but feel free to do so.)
Sorry that was just a mistake.
The point is to configure the data collection configuration for the
currently existing meters differently for
On Wed, Jan 08 2014, Ildikó Váncsa wrote:
My idea was just about providing the possibility to configure the data
collection in Ceilometer differently for the different tenants, I didn't
mean to link it to an API or at least not on the first place. It could be
done by the operator as well, for
Hi,
My idea was just about providing the possibility to configure the data
collection in Ceilometer differently for the different tenants, I
didn't mean to link it to an API or at least not on the first place.
It could be done by the operator as well, for instance, if the polling
-
From: Neal, Phil [mailto:phil.n...@hp.com]
Sent: Tuesday, January 07, 2014 11:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
For multi-node deployments, implementing something like inotify would
restarts)
Tim
From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com]
Sent: 08 January 2014 19:27
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Wed, Jan 8, 2014 at 12:35 PM, Ildikó Váncsa
ildiko.van
From: ext Doug Hellmann [doug.hellm...@dreamhost.com]
Sent: Wednesday, January 08, 2014 8:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic
: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Wed, Jan 8, 2014 at 12:35 PM, Ildikó Váncsa ildiko.van...@ericsson.com
wrote:
Hi Doug,
Answers inline again.
Best Regards,
Ildiko
On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa ildiko.van...@ericsson.com
wrote:
Hi
, January 08, 2014 8:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Wed, Jan 8, 2014 at 12:35 PM, Ildikó Váncsa
ildiko.van...@ericsson.com wrote:
Hi Doug,
Answers inline again
Hi Doug,
OK, so like I said, we did not design the system with the idea that a user of
the cloud (rather than the deployer of the cloud) would have any control over
what data was collected. They can ask questions about only some of the data,
but they can't tell ceilometer what to collect.
I need to add an additional layer of authorization between auth_token and
the reporting API.
I know it's as simple as creating a WSGI element and adding it to the
pipeline. Examining the code I haven't figured out where to begin doing
this.
I'm not using Apache and mod_wsgi, just the
Hi,
Here is how we are doing this for Solum:
Keystone auth:
https://github.com/stackforge/solum/blob/master/solum/api/auth.py
Additional Hook: https://review.openstack.org/#/c/64458/ (auth.py for hook
code and config.py for hooks)
Here is an e-mail thread with discussion:
Hi, guys.
jay wrote:
So you are saying that the Synaps server is storing 14,400,000 samples
in memory (2 days of 5000 samples per minute)? Or are you saying that
Synaps is storing just the 5000 alarm records in memory and then
processing (determining if the alarm condition was met) the
From: ext Chmouel Boudjnah [mailto:chmo...@enovance.com]
Sent: Monday, January 06, 2014 2:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata
On Mon, 2014-01-06 at 00:14 +, Deok-June Yi wrote:
Hi, Ceilometer team.
I'm writing to share my load test result and ask you for advice about
Ceilometer.
Before starting, for whom doesn’t know Synaps [1], Synaps is
'monitoring as a service' project that provides AWS CloudWatch
- FI/Espoo)
[mailto:vijayakumar.kodam@nsn.com]
Sent: Tuesday, January 07, 2014 2:49 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: chmo...@enovance.com
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
From: ext Chmouel Boudjnah [mailto:chmo
On Tue, Dec 31 2013, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)
wrote:
Hi,
Currently there is no way to enable or disable meters without restarting
ceilometer.
There are cases where operators do not want to run all the meters
continuously.
In these cases, there should be a
-Original Message-
From: ext Julien Danjou [mailto:jul...@danjou.info]
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Tue, Dec 31 2013, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)
wrote:
Hi,
Currently there is no way to enable or disable
On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata Consultancy
Ser - FI/Espoo) vijayakumar.kodam@nsn.com wrote:
In this case, simply changing the meter properties in a configuration file
should be enough. There should be an inotify signal which shall notify
ceilometer of the
On Mon, Dec 30, 2013 at 2:53 PM, David Kranz dkr...@redhat.com wrote:
On 12/27/2013 05:27 AM, Nadya Privalova wrote:
Hello guys!
I hope all of you are enjoying the holidays! But I'd like to raise a
Tempest question. Again. I hope this email will not be lost after vacations
:)
On Tue, Dec 31, 2013 at 4:53 AM, Kodam, Vijayakumar (EXT-Tata Consultancy
Ser - FI/Espoo) vijayakumar.kodam@nsn.com wrote:
Hi,
Currently there is no way to enable or disable meters without restarting
ceilometer.
There are cases where operators do not want to run all the meters
be relevant in scoping out the
blueprint and subsequent changes
Tim
From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com]
Sent: 06 January 2014 23:35
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
On Tue
Excerpts from Herndon, John Luke's message of 2014-01-03 08:17:15 -0800:
On 1/2/14, 7:06 PM, Sean Dague s...@dague.net wrote:
On 01/02/2014 08:36 PM, Robert Collins wrote:
On 3 January 2014 14:34, Robert Collins robe...@robertcollins.net
wrote:
On 3 January 2014 12:40, Herndon, John
On 01/02/2014 10:46 PM, Herndon, John Luke wrote:
On 1/2/14, 11:36 AM, Gordon Sim g...@redhat.com wrote:
On 12/20/2013 09:26 PM, Herndon, John Luke wrote:
On Dec 20, 2013, at 12:13 PM, Gordon Sim g...@redhat.com wrote:
On 12/20/2013 05:27 PM, Herndon, John Luke wrote:
Other protocols
On 1/2/14, 7:06 PM, Sean Dague s...@dague.net wrote:
On 01/02/2014 08:36 PM, Robert Collins wrote:
On 3 January 2014 14:34, Robert Collins robe...@robertcollins.net
wrote:
On 3 January 2014 12:40, Herndon, John Luke john.hern...@hp.com
wrote:
On 1/2/14, 4:27 PM, Clint Byrum
On 12/20/13, 11:57 PM, Jay Pipes jaypi...@gmail.com wrote:
On 12/20/2013 04:43 PM, Julien Danjou wrote:
On Fri, Dec 20 2013, Herndon, John Luke wrote:
I think there is probably a tolerance for duplicates but you¹re right,
missing a notification is unacceptable. Can anyone weigh in on how
On 12/20/2013 09:26 PM, Herndon, John Luke wrote:
On Dec 20, 2013, at 12:13 PM, Gordon Sim g...@redhat.com wrote:
On 12/20/2013 05:27 PM, Herndon, John Luke wrote:
Other protocols may support bulk consumption. My one concern with
this approach is error handling. Currently the executors
On 1/2/14, 11:36 AM, Gordon Sim g...@redhat.com wrote:
On 12/20/2013 09:26 PM, Herndon, John Luke wrote:
On Dec 20, 2013, at 12:13 PM, Gordon Sim g...@redhat.com wrote:
On 12/20/2013 05:27 PM, Herndon, John Luke wrote:
Other protocols may support bulk consumption. My one concern with
Hi,
I¹m working on adding a vertica (www.vertica.com) storage driver to
ceilometer. I would love to get this driver into upstream. However, I¹ve
run into a bit of a snag with the tests. It looks like all of the existing
storage drivers have ³in-memory² versions that are used for unit tests.
Excerpts from Herndon, John Luke's message of 2014-01-02 15:16:26 -0800:
Hi,
I¹m working on adding a vertica (www.vertica.com) storage driver to
ceilometer. I would love to get this driver into upstream. However, I¹ve
run into a bit of a snag with the tests. It looks like all of the existing
On 1/2/14, 4:27 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Herndon, John Luke's message of 2014-01-02 15:16:26 -0800:
Hi,
I¹m working on adding a vertica (www.vertica.com) storage driver to
ceilometer. I would love to get this driver into upstream. However, I¹ve
run into a bit
On Thu, Jan 2, 2014 at 5:36 PM, Robert Collins
robe...@robertcollins.net wrote:
On 3 January 2014 14:34, Robert Collins robe...@robertcollins.net wrote:
On 3 January 2014 12:40, Herndon, John Luke john.hern...@hp.com wrote:
On 1/2/14, 4:27 PM, Clint Byrum cl...@fewbar.com wrote:
I don’t
On 01/02/2014 08:36 PM, Robert Collins wrote:
On 3 January 2014 14:34, Robert Collins robe...@robertcollins.net wrote:
On 3 January 2014 12:40, Herndon, John Luke john.hern...@hp.com wrote:
On 1/2/14, 4:27 PM, Clint Byrum cl...@fewbar.com wrote:
I don’t think it would be that hard to
On 12/27/2013 05:27 AM, Nadya Privalova wrote:
Hello guys!
I hope all of you are enjoying the holidays! But I'd like to raise a
Tempest question. Again. I hope this email will not be lost after
vacations :)
After the summit we decided to track all tests that are being created
for Ceilometer
Hello all,
Thank you for your suggestions about tracking bps. I'll create a
spreadsheet.
David,
1. https://review.openstack.org/#/c/55276/ is ready for review
2. We decided to move base.py to a separate change request:
https://review.openstack.org/#/c/64304/ to make it merged ASAP. But now I
I think the better way is save meters as a field in resource table.
You can look at MongoDB model and may get some ideas.
Beside above, sql backend can introduce Memcache to improve performance.
IMO, the best way may be redesign the sql model to match workload.
On Sat, Dec 28, 2013 at 6:51
On 12/28/2013 05:51 AM, 刘胜 wrote:
Hi all：
I have reported a bug about time consuming of “resource-list” in
ceilometer CLI：
https://bugs.launchpad.net/ceilometer/+bug/1264434
In order to Identify the causes of this phenomenon, I have pdb the codes
in my invironment(configured mysql as db
Hello guys!
I hope all of you are enjoying the holidays! But I'd like to raise a
Tempest question. Again. I hope this email will not be lost after vacations
:)
After the summit we decided to track all tests that are being created for
Ceilometer in Tempest here:
901 - 1000 of 1286 matches
Mail list logo
