On 22/06/15 09:02 AM, Sean Dague wrote:
On 06/22/2015 08:58 AM, Doug Hellmann wrote:
Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400:
In extracting the contract for RPC backends in devstack (to have most of
them live in plugins) one bit of an edge case was discovered.
not a core myself, apologies if this is spamming, but +1. Jordan's been
a great help.
On 22/06/15 04:23 PM, Matthew Treinish wrote:
Hi Everyone,
I'd like to propose we add Jordan Pittier (jordanP) to the tempest core team.
Jordan has been a steady contributor and reviewer on tempest over the
On 22/06/15 06:39 PM, Chris Dent wrote:
On Mon, 22 Jun 2015, Sean Dague wrote:
Could we deprecate the use of tranport_url in ceilometermiddleware and
move to an actual oslo.config file somewhere instead? That would bring
it in line with the rest of the RPC configuration for services, and
On 21/08/2015 4:58 AM, Thierry Carrez wrote:
Anne Gentle wrote:
Hi all,
In last week's TC Highlights blog post [1] I asked if there is interest
in moving the cross-project meeting. Historically it is held after the
TC meeting, but there isn't a requirement for those timings to line up.
I've
good questions...
On 17/08/2015 10:19 AM, Igor Degtiarov wrote:
Gordon probably that question to you:
Are we going to create a new folder in spec's dir for next cycle, or
we continue discussing new specs as part of liberty?
we can create a new dir for M* cycle specs. as mentioned in last
On 30/07/2015 1:55 PM, Srikanth Vavilapalli wrote:
I was able to resolve this issue by adding the following configuration line (by
default, disable_non_metric_meters is set to True, and most of the Neutron
meters are of type non-metric) in /etc/ceilometer/ceilometer.conf and
restarting all
On 07/08/2015 3:49 AM, Chris Dent wrote:
Despite our conversation in the meeting yesterday[1] I still remain a
bit confused about the upgrade path from alarming-in-ceilometer to
alarming provided by aodh and the availability of the older code in
released liberty.
Much of my confusion can
hi Igor,
i would suggest you go with second option as i believe your
implementation will overlap and reuse some of the functionality Ryota
would code for his alarm spec [1]. also, since Aodh is working on an
independent release cycle, it'll give you some more time as i don't
think we'd be
On 07/08/2015 3:49 AM, Chris Dent wrote:
Despite our conversation in the meeting yesterday[1] I still remain a
bit confused about the upgrade path from alarming-in-ceilometer to
alarming provided by aodh and the availability of the older code in
released liberty.
Much of my confusion can
On 16/07/2015 12:05 AM, Angus Salkeld wrote:
Will this be hidden within the client so that as long as we have aodh
enabled in our gate's devstack
this will just work?
yes, we discussed this last week during our midcycle. the plan going
forward is to allow current existing Ceilometer alarm
thanks Ildiko
it's also safe to assume the meeting will be cancelled for October 29
and November 5. please use the mailing list (it's actually preferred)
for any discussion items.
On 21/10/2015 8:22 AM, Ildikó Váncsa wrote:
Hi All,
I would like to inform you that we cancel the Ceilometer
thanks for the feedback folks.
i'd like to welcome Ryota to the Aodh core team. thank you for all the
continued effort in building alarming functionality in OpenStack!
On 16/10/2015 8:59 AM, gord chung wrote:
sorry, as we usually do, please comment on gerrit[1]. if you cannot,
then please
hi,
seems like a neat idea, i had a few questions after watching the
presentation from Vancouver.
- is Watcher streaming the data captured by Ceilometer or is it querying
the Ceilometer db?
- is it utilising the Event data captured by Ceilometer or metric data?
both?
- i notice there's a
again, it's been debated that we shouldn't be allowed to completely drop
apis.
in regards to deprecation, how do you make this deprecation known? also,
this goes beyond the client. if we deprecated in the client we should
really have the endpoint deprecated in API as well.
On 05/11/2015
for reference, Julien is currently signed up for that task[1]. if this
is a high priority requirement, we might want to see if another resource
can pick it up, we can help out to explain how it should all be done :)
cheers,
[1] https://etherpad.openstack.org/p/mitaka-telemetry-todos
On
hi,
i was doing some googling on the current state of time series databases
to see if there was a worthwhile db to implement as a Gnocchi driver and
it seems we're currently in the same state as before: there are flaws
with all open source time series databases but if you have lots of
money,
can you clarify what you mean by 'zombie process'? i'm not aware of a
bug relating to this so could you open one.
just for reference, this is the suggested method for deploying the
ceilometer-api:
http://docs.openstack.org/developer/ceilometer/install/mod_wsgi.html
cheers,
On 12/11/2015
On 11/11/2015 4:19 AM, Julien Danjou wrote:
Yes, I think there is. We should write typical use cases and example in
the documentation so that people may get a grasp of what Gnocchi is and
what kind of problem it can or cannot solve.
cool stuff... how should we start this? etherpad[1]? i think
if you have configured two workers and you have two ceilometer-api
processes and an extra 'zombie' process, then it's correct.
someone else might be able to articulate this better but when you use
workers, it creates child processes that represent the workers you set,
and there is a parent
hi,
you may have noticed that changes are in motion and an extra telemetry
tag being floated around. the following is your coles|cliff|spark notes
on what you need to know.
-- background --
three years ago, the ceilometer project was created to tackle the
billing of cloud environments.
in Liberty, we did a virtual meetup in for the telemetry team so i
thought i'd share experience.
On 16/11/2015 9:05 AM, Jim Rollenhagen wrote:
Then we can set up some hangouts (or similar) to get people in the same
"room" working on things. Time zones will get weird, but we tend to
hangouts is
do we require a major versioning bump for this? i'm wondering how
'breaking' this is in real life if all the services have dropped py2.6
already. maybe this just requires an upper-cap in appropriate stable
branches?
to be devils advocate, one (arguably terrible) reason for not doing a
major
On 16/11/2015 11:13 AM, Doug Hellmann wrote:
does anyone want to sign up to remove that last
namespace package?
already in action: https://review.openstack.org/#/c/243255/
--
gord
__
OpenStack Development Mailing
thanks for the feedback.
it's my pleasure to welcome Rohit to the Ceilometer core team. everyone
back to work! :)
On 05/11/15 08:45 AM, gord chung wrote:
hi folks,
i'd like to nominate Rohit Jaiswal as core for Ceilometer. he's done a
lot of good work recently like discovering and fixing
let's change this gate to experimental for now.
On 17/11/15 05:10 AM, Julien Danjou wrote:
Hi,
So we recently decided to run the functional tests for the HBase driver
and enabled the gate job. It turned out the gate job didn't worked, so I
tried to fix it. Now it's almost fixed, and it run the
hi folks,
i want to start off by thanking everyone for joining the telemetry
related discussions at the Tokyo summit -- we got some great feedback
and ideas. similar to the last summit, here's a rundown of items that we
talked about[1] and will be tracking in the upcoming cycle. as before,
On 05/11/2015 1:06 PM, Nader Lahouti wrote:
Hi Doug,
I have an app that listens to notifications and used the info provided in
http://docs.openstack.org/developer/oslo.messaging/notification_listener.html
Basically I create
1. NotificationEndpoints(object):
to be stop() and then wait() there as well?
Thanks,
Nader.
On Thu, Nov 5, 2015 at 10:19 AM, gord chung <g...@live.ca
<mailto:g...@live.ca>> wrote:
On 05/11/2015 1:06 PM, Nader Lahouti wrote:
Hi Doug,
I have an app that listens to notifications and u
hi all,
after discussions on the usefulness of a Telemetry mid-cycle, we've
decided to forego having an in-person mid-cycle for Mitaka. to avoid
rehashing already discussed items, see: same reasons as Glance[1]. much
thanks to jasonamyers for offering a venue for a Telemetry mid-cycle.
that
apologies, if the below was mentioned at some point in this thread.
On 04/11/2015 10:42 AM, Sean Dague wrote:
This seems like a fundamental abuse of HTTP honestly. If you find
yourself creating a ton of new headers, you are probably doing it wrong.
if we want to explore the HTTP path, did we
we actually had a solution implemented in Ceilometer to handle this[1].
that said, based on the results of our survey[2], we found that most
operators *never* update configuration files after the initial setup and
if they did it was very rarely (monthly updates). the question related
to
On 05/11/2015 5:11 AM, Raghunath D wrote:
Hi Pradeep,
Presently we are looking for a monitoring service.Using monitoring
service user's/application's
will subscribe for few notification's/events from openstack
infrastructure and monitoring service
will publish these notification to
i'm sort of torn on this item. there's a general feeling that regarding
api, nothing should be dropped so i'm hesitant to actually deprecate it.
i think changing the data also is very dangerous when it comes to
compatibility (even though keeping it increases inconsistency).
maybe the better
hi folks,
i'd like to nominate Rohit Jaiswal as core for Ceilometer. he's done a
lot of good work recently like discovering and fixing many issues with
Events and implemented the configuration reloading functionality. he's
also been very active providing input and fixes for many bugs.
as
hi folks,
to followup on an item regarding Ceilometer+ops session at the summit.
there isn't one explicitly for Ceilometer but there is a monitoring
session[1] and a billing session[2]. based on the past, these sessions
tend to focus more on 3rd party tools such as Sensu et al but if free it
hi,
i'd like to nominate Ryota Mibu to the Aodh core team. he has been an
active participant in Aodh and leads the Event alarms work done there.
he also brings good insight related to NFV use case.
patches:
https://review.openstack.org/#/q/owner:%22Ryota+MIBU%22+project:openstack/aodh,n,z
sorry, as we usually do, please comment on gerrit[1]. if you cannot,
then please comment here.
[1] https://review.openstack.org/#/c/235890/
On 16/10/15 08:39 AM, gord chung wrote:
hi,
i'd like to nominate Ryota Mibu to the Aodh core team. he has been an
active participant in Aodh and leads
which backend are you using? this potentially may be a bug where we're
hitting some size limit restricted by datatype.
On 19/10/2015 4:02 PM, Srikanth Vavilapalli wrote:
Hi
I have observed "inf" values for "sum" and "average" fields in a ceilometer statistics query on one of my custom meter
, Srikanth Vavilapalli wrote:
Hi
I am using MongoDB backend.
Thanks
Srikanth
-Original Message-
From: gord chung [mailto:g...@live.ca]
Sent: Tuesday, October 20, 2015 9:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum
hi,
for those interested, i've put up the tentative schedule[1] for
telemetry-related topics for the Tokyo design summit.
note, there's a session to discuss horizon and ceilometer integration as
that was a common issue raised in the recent ceilometer survey.
please let me know if there's
hi,
telemetry is a big space and its requirements differ from company to
company. there are existing projects that extend/leverage the
functionality of Ceilometer to either customise, fill in gaps or resolve
complementary problems.
as the projects are not all managed by the Ceilometer team,
hi,
there has been a lot of work done across the community and Ceilometer
relating to versionedobjects. in Ceilometer particularly, this effort
has somewhat stalled as contributors are unsure of the benefits of
versionedobjects and how it relates to Ceilometer. there was a little
skeptism
On 28/08/15 12:18 PM, Roman Dobosz wrote:
So imagine we have new versions of the schema for the events, alarms or
samples in ceilometer introduced in Mitaka release while you have all
your ceilo services on Liberty release. To upgrade ceilometer you'll
have to stop all services to avoid data
hi
i'm reaching out for help understanding meter values across hypervisors.
for context, we have an open bug in Ceilometer where the value used to
capture cputime of an instance is being reset whenever the instance is
restarted or shutdown[1]. this seems to be the expected behaviour for
On 31/08/2015 1:06 PM, Julien Danjou wrote:
On Mon, Aug 31 2015, gord chung wrote:
for context, we have an open bug in Ceilometer where the value used to capture
cputime of an instance is being reset whenever the instance is restarted or
shutdown[1]. this seems to be the expected behaviour
On 01/09/2015 12:10 PM, Julien Danjou wrote:
On Tue, Sep 01 2015, gord chung wrote:
but if it's not actually cumulative in Ceilometer (pre-storage), should we
really be tagging it as such?
We only have 3 meters type, and the cumulative definition I wrote
somewhere back in 2012 states
On 28/08/2015 5:18 PM, Alec Hothan (ahothan) wrote:
On 8/28/15, 11:39 AM, "gord chung" <g...@live.ca> wrote:
i should start by saying i re-read my subject line and it arguably comes
off aggressive -- i should probably have dropped 'explain' :)
On 28/08/15 01:47 PM, Alec
hi,
we'd like to nominate Liusheng to the Ceilometer core team. he has been
a leading contributor in Ceilometer, provides solid reviews, and
regularly adds ideas for new improvements.
as we did last time, please vote here:
https://review.openstack.org/#/c/218819/ . if for whatever reason
hi,
we'd like to nominate Pradeep Kilambi to the Ceilometer core team. he
has contributed by adding declarative meter support in Ceilometer and
provides feedback/input in regards to packaging and design.
as we did last time, please vote here:
https://review.openstack.org/#/c/218822/ . if
On 04/09/2015 6:14 AM, Thierry Carrez wrote:
Hi PTLs,
Here is the proposed slot allocation for every "big tent" project team
at the Mitaka Design Summit in Tokyo. This is based on the requests the
liberty PTLs have made, space availability and project activity &
collaboration needs.
We have
On 28/08/15 01:54 PM, Dan Smith wrote:
we store everything as primitives: floats, time, integer, etc... since
we need to query on attributes. it seems like versionedobjects might not
be useful to our db configuration currently.
I don't think the former determines the latter -- we have lots of
On 31/08/15 09:18 AM, gord chung wrote:
hi,
we'd like to nominate Liusheng to the Ceilometer core team. he has
been a leading contributor in Ceilometer, provides solid reviews, and
regularly adds ideas for new improvements.
as we did last time, please vote here:
https
On 31/08/15 09:13 AM, gord chung wrote:
hi,
we'd like to nominate Pradeep Kilambi to the Ceilometer core team. he
has contributed by adding declarative meter support in Ceilometer and
provides feedback/input in regards to packaging and design.
as we did last time, please vote here:
https
hi all,
as you may have heard, in an effort to simplify OpenStack Telemetry
(Ceilometer) and streamline it's code, the alarming functionality
provided by OpenStack Telemetry has been moved to it's own
repository[1]. The new project is called Aodh[2]. the idea is that Aodh
will grow as it's
On 08/09/2015 5:29 PM, Sean Dague wrote:
On 09/08/2015 03:32 PM, Doug Hellmann wrote:
Excerpts from Sean Dague's message of 2015-09-08 14:11:48 -0400:
On 09/08/2015 01:07 PM, Doug Hellmann wrote:
Excerpts from Dean Troyer's message of 2015-09-08 11:20:47 -0500:
On Tue, Sep 8, 2015 at 9:10
On 07/09/2015 1:59 PM, Bhagyashree Uday wrote:
Hi ,
I am Bhagyashree from India(IRC nick : bee2502 ). I have previous
experience in data analytics including Machine Leraning,,NLP,IR and
User Experience Research. I am interested in contributing to OpenStack
on projects involving data
On 02/09/2015 11:25 AM, Alec Hothan (ahothan) wrote:
On 9/1/15, 11:31 AM, "gord chung" <g...@live.ca> wrote:
re: serialisation, that probably isn't the biggest concern for
Ceilometer performance. the main items are storage -- to be addressed by
Gnocchi/tsdb, and poll
On 31/08/2015 3:36 PM, Julien Danjou wrote:
On Mon, Aug 31 2015, gord chung wrote:
i'm not sure Gnocchi is where we should be fixing this as it really only
(potentially) fixes it for Gnocchi and not for any of the other ways Ceilometer
data can be consumed.
The ideal way is to send the data
is this using libvirt? if so, can you verify you have the following
requirements:
* libvirt 1.1.1+
* qemu 1.5+
* guest driver that supports memory balloon stats
also, please check to see if there are any visible ERRORs in
ceilometer-agent-compute log.
On 08/09/2015 2:04 AM, Abhishek
hi,
as mentioned during today's meeting, since we have our slots for design
summit, we'll start accepting proposals for the telemetry-related topics
for the Tokyo summit.
similar to previous design summits, anyone is welcome to propose topics
related to ceilometer, aodh, gnocchi, or any
is this using KVM? there are actually a few requirements[1] to ensure
memory.usage meter works using libvirt:
- libvirt 1.1.1+
- qemu 1.5+
- guest driver that supports memory balloon stats
retagging to ceilometer to get more eyes.
[1]
On 11/09/2015 3:26 PM, Joshua Harlow wrote:
Hi all,
I was reading over the TC IRC logs for this week (my weekly reading)
and I just wanted to let my thoughts and comments be known on:
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309
I feel it's very
hi folks,
less than six months ago, i decided to run for PTL of Ceilometer where
my main goal was to support the community of contributors that exists
within OpenStack with interests in telemetry[1]. it is under that tenet
which i will run again for team lead of Ceilometer. as mentioned
thanks for organising this Jason.
for those who can't attend but want to, i think it'd also be good to
know if location is the blocker here.
retagging with [ceilometer].
On 15/09/2015 9:50 AM, Jason Myers wrote:
Hello Everyone,
We are setting up a few polls to determine the possibility
hi,
i'm not familiar with eclipse+pydev but you should be able to run that
command as is in terminal
'./tools/ceilometer-test-event.py'
the main question i have is what are you trying to debug? that script,
to be honest, does not do much. it seems to just test the event
conversion
On 10/09/2015 7:26 PM, Tony Breeds wrote:
Hi all,
In trying to fix a few stable/juno issues we need to release a new version
of ceilometerclient for stable/juno. This email is to try and raise awareness
so that if the proposal is bonkers [1] we can come up with something better.
This
On 03/09/2015 4:02 PM, Dan Smith wrote:
- do we need to migrate the db to some handle different set of
>attributes and what happens for nosql dbs?
No, Nova made no schema changes as a result of moving to objects.
so i don't really understand how this part works. if i have two
collectors --
Hello,
The OpenStack Telemetry (aka Ceilometer) team would like to collect
feedback and information from its user base in order to drive future
improvements to the project. To do so, we have developed a survey. It
should take about 15min to complete.
Questions are fairly technical, so please
hi,
just a reminder, please submit any topics ASAP so we can properly vote
on items. if you have a feature you'd like to submit this cycle it'd
greatly help your chances of merging should you present/explain your
topic to us common folks.
On 10/09/15 02:03 PM, gord chung wrote:
hi
On 28/08/15 12:49 PM, Dan Smith wrote:
there was a little skeptism because it was originally sold as magic,
but reading the slides from Vancouver[1], it is not magic.
I think I specifically said they're not magic in my slides. Not sure
who sold you them as magic, but you should leave them a
i should start by saying i re-read my subject line and it arguably comes
off aggressive -- i should probably have dropped 'explain' :)
On 28/08/15 01:47 PM, Alec Hothan (ahothan) wrote:
On 8/28/15, 10:07 AM, gord chung g...@live.ca wrote:
On 28/08/15 12:18 PM, Roman Dobosz wrote:
So
On 28/08/15 02:48 PM, Julien Danjou wrote:
Hi fellows,
Ilya did a few good contributions to Gnocchi, especially around the
InfluxDB driver, so I'm glad to add him to the list of core reviewers.
Welcome aboard.
Cheers,
we had this in ceilometer events. you can see it here:
https://github.com/openstack/ceilometer/commit/898cd3d036c4358aa16f7b3e2028365dc9829213
note, that patch is removing it because it slowed everything way down
because of locking. if you can avoid it, avoid it.
On 08/12/2015 7:28 AM, Renat
On 10/12/15 12:04 PM, Matthew Treinish wrote:
Using this query to see how many deprecation warning we emit on jobs running on
master in the past 7 days:
On 16/12/2015 4:24 PM, Lu, Lianhao wrote:
On Dec 16, 2015 14:13, Chris Dent wrote:
On Wed, 16 Dec 2015, Lu, Lianhao wrote:
In ceilometer, some metrics(e.g. network.incoming.bytes for VM net
interface, hardware.network.incoming.bytes for host net interface,
compute.node.cpu.percentage for
wasn't aware this project existed. i've contacted flwang.
just for reference, for those that extend Telemetry projects, it's good
to promote it here:
https://wiki.openstack.org/wiki/Telemetry#Externally_Managed
On 14/12/2015 4:09 AM, Andreas Jaeger wrote:
On 12/14/2015 10:01 AM, Steve
On 17/12/15 08:17 AM, AFEK, Ifat (Ifat) wrote:
What do you mean by "create new types of resources"?
Suppose we want to add a new resource type with a new id format, what
should we do for that? Change Gnocchi code / add a plug-in / add a
new type definition in the database / ...?
i believe
sorry, my email was blocking the list for a bit so i missed this.
the original reason this was implemented i believe was to track alarm
state changes as an event in ceilometer events. i still see this as a
valid use case but it does duplicate some of the functionality of alarm
history.
i
On 06/01/2016 8:11 AM, AFEK, Ifat (Ifat) wrote:
Hi,
We would like to be notified once an alarm state is changed, so we prefer using
the message bus.
As far as I understand, ceilometer and aodh APIs do not provide immediate
notifications. If we use the APIs, we will have to poll the data
On 08/01/16 04:49 AM, Julien Danjou wrote:
On Thu, Jan 07 2016, Jay Pipes wrote:
OK, I just watched that. Sorry, still don't see the value that Mimic provides
over unit testing the client interfaces and mocking out the HTTP payloads so
you have strict control over the expectations.
The
hi folks,
just to recap the meeting item[1], we won't have a meetup this cycle as
we all have our tasks and there doesn't seem to be any items that are
controversial. we've agree that going forward, if something does require
quicker feedback than ML/irc, we'll set up a conference and promote
shall we try to synchronise the two datapoints more than? i think that'd
be the better route since pollster and notification values are
attempting to meter the same thing.
On 21/12/2015 8:33 AM, Luo Gangyi wrote:
gord, I have looked your link, seems related.
But still, image_ref is a problem.
hi folks,
before i forget, we'll be skipping meetings the next two weeks (24th and
31st). we'll resume regularly scheduled meetings on Jan 7th.
please raise anything important to the mailing list (as normal).
have a nice holidays.
cheers,
--
gord
we actually looked at this problem here:
https://review.openstack.org/#/c/235702/
i think we should add support of new attribute instead.
On 20/12/2015 10:52 AM, Luo Gangyi wrote:
Hi devs,
I found a problem which may cause infinite update of instance's
attributes in gnocchi.
Let's see the
again due to
internal-interface mocking?
On Tue, Nov 24, 2015 at 11:24 AM, gord chung <g...@live.ca
<mailto:g...@live.ca>> wrote:
mriedem and myself resolved this with keystone folks earlier
today[1]. should be all better now [2]
[1]
http://eavesdrop.openstack
On 23/11/2015 11:14 AM, AFEK, Ifat (Ifat) wrote:
I guess I would like to do both: create a new alarm definition, then
trigger it (call alarm_actions), and possibly later on set its state
back to OK (call ok_action).
I understood that currently all alarm triggering is internal in AODH,
mriedem and myself resolved this with keystone folks earlier today[1].
should be all better now [2]
[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2015-11-24.log.html#t2015-11-24T14:38:39
[2] https://review.openstack.org/#/c/249268/
On 24/11/15 12:33 PM, Alan
hi,
just a quick note, i'll be tagging the Mitaka-1 release early next week
for Ceilometer and Aodh. if you want to get something in for M-1, now is
the time. please let us know so we can track it.
Gnocchi will not have a release -- it will continue to be released
independently as features
On 20/11/15 11:33 AM, Alexis Lee wrote:
gord chung said on Thu, Nov 19, 2015 at 11:59:33PM -0500:
just to clarify, the idea doesn't involve tailoring the notification
payload to ceilometer, just that if a producer is producing a
notification it knows contains a useful datapoint, the producer
ceilometer cares. we listen to all notifications and build Measurement
and Event data from (some of) them. to be honest, i don't know if
changes in nova notifications have/are broken in ceilometer because
quite frankly there are far too many notifications to test and track.
as a consumer of
On 19/11/15 10:26 PM, Srikanth Vavilapalli wrote:
Hi Gord
On your second point, Yes, Ceilometer does provide a framework to
capture a notification and republish to multiple “publish targets” in
addition to the collector service using udp/kafka/notification as the
transport mechanisms… We
On 19/11/15 08:53 PM, Matt Riedemann wrote:
On 11/19/2015 5:52 PM, gord chung wrote:
ceilometer cares. we listen to all notifications and build Measurement
and Event data from (some of) them. to be honest, i don't know if
changes in nova notifications have/are broken in ceilometer because
On 20/11/2015 5:12 PM, Chris Dent wrote:
On Fri, 20 Nov 2015, gord chung wrote:
i think a lot of the complexity we have in versioning is that the
projects are too silo'd. i think some of the versioning issues would
be irrelevant if the producer knew it's consumers before sending
rather
given John's reply, i think we should start a new thread? apologies for
hijacking log thread.
On 23/11/2015 5:01 AM, Alexis Lee wrote:
gord chung said on Fri, Nov 20, 2015 at 01:32:02PM -0500:
On 20/11/15 11:33 AM, Alexis Lee wrote:
why would a producer spit out non-useful datapoints
On 22/11/2015 10:04 PM, Srikanth Vavilapalli wrote:
We have found a related blueprint *[1],* which is exactly addressing
this dynamic provisioning of pipelines via an API and making use of a
new data store to store this configuration. But seems like that
blueprint was abandoned due its
hi Ifat,
i added some questions below.
On 23/11/2015 7:16 AM, AFEK, Ifat (Ifat) wrote:
Hi,
We have a couple of questions regarding AODH alarms.
In Vitrage[1] project we have two use cases that involve Ceilometer:
1. Import Ceilometer alarms, as well as alarms and resources from other
not a fan of these changes since it messes up git blame and it becomes
harder to track down author if you have questions relating to bug/code.
that said, "if var > 0" is not the same as "if var". in the latter, var
can be any number (negative or positive) or any other datatype and it'll
so one point i should mention is that the notification we propose on
removing was originally attended for Ceilometer events. much in same way
as disabling the aodh-notifier to allow Vitrage to consume alarm
triggers, it isn't exactly safe for Vitrage to consume the existing
messages as
hi,
please ensure you are running latest code (as you seem to want master)
you are running into
https://review.openstack.org/#/q/I4765b3b9627983a245aa5521a85ad89e83ab8551
On 14/01/2016 12:10 AM, lichen.hangzhou wrote:
Hi,
I have installed a devstack environment with ceilometer enabled:
On 21/01/2016 11:27 AM, Doug Hellmann wrote:
You can also do this using Python's json module from the command line:
$ echo '{"json":"obj"}' | python -m json.tool
{
"json": "obj"
}
Doug
very useful... if you want a site, i use http://pro.jsonlint.com/
(vladikr told me about it... he
1 - 100 of 103 matches
Mail list logo
