[openstack-dev] [ceilometer][aodh][vitrage] Vitrage project

[AFEK, Ifat (Ifat)]

Hi Ceilometer/AODH developers,

As you might have heard in Mitaka Summit, we have started a new project named 
Vitrage[1]. We would like it to be the Openstack RCA (Root Cause Analysis) 
Engine for organizing, analyzing and expanding OpenStack alarms & events, 
yielding insights regarding the root cause of problems and deducing the 
existence of problems before they are directly detected.

We are now in the process of reviewing the blueprints[2] that we wish to 
implement in mitaka. We would be happy to get your reviews as well, as Vitrage 
should work with AODH alarms - get AODH alarms as input, produce RCA insights, 
and optionally generate new deduced alarms. 

Your feedback would be highly appreciated.

[1] https://wiki.openstack.org/wiki/Vitrage
[2] https://blueprints.launchpad.net/vitrage 

Thanks,
Ifat Afek.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] zombie process after ceilometer-api

[Madhu Mohan Nelemane]

Hi,

I see a zombie process left out by ceilometer-api after a client command
like "ceilometer meter-list".  This seems to occur only when I change the
number of workers for [api] section in ceilometer.conf to 2 or more.
With default  value of workers = 1, there is no zombie.

Has anybody encountered this problem ? OR is there already a bug to tackle
this ?

Thanks,
Madhu Mohan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] zombie process after ceilometer-api

[Madhu Mohan Nelemane]

Here is the output of "ps aux | grep ceilometer-api" after "ceilometer
meter-list"

ceilome+ 27192  1.0  1.1 247400 60388 ?Ss   14:10   0:00
/usr/bin/python /usr/bin/ceilometer-api
--config-file=/etc/ceilometer/ceilometer.conf
--logfile=/var/log/ceilometer/api.log
ceilome+ 27655 15.3  0.0  0 0 ?Z14:11   0:00
[ceilometer-api] 

Its the second line I am concerned about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] zombie process after ceilometer-api

[gord chung]

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 8:37 AM, Madhu Mohan Nelemane wrote:

Hi,

I see a zombie process left out by ceilometer-api after a client 
command like "ceilometer meter-list".  This seems to occur only when I 
change the number of workers for [api] section in ceilometer.conf to 2 
or more.

With default  value of workers = 1, there is no zombie.

Has anybody encountered this problem ? OR is there already a bug to 
tackle this ?


Thanks,
Madhu Mohan


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] zombie process after ceilometer-api

[gord chung]

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 process which manages them.


you'll probably notice the same if you configure addition 
collector/notification agent workers... and the same for other projects


cheers,

On 12/11/15 09:26 AM, Madhu Mohan Nelemane wrote:
Here is the output of "ps aux | grep ceilometer-api" after "ceilometer 
meter-list"


ceilome+ 27192  1.0  1.1 247400 60388 ?Ss   14:10   0:00 
/usr/bin/python /usr/bin/ceilometer-api 
--config-file=/etc/ceilometer/ceilometer.conf 
--logfile=/var/log/ceilometer/api.log
ceilome+ 27655 15.3  0.0  0 0 ?Z14:11   0:00 
[ceilometer-api] 


Its the second line I am concerned about.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] proposal to add Rohit Jaiswal to Ceilometer core

[gord chung]

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 many issues with 
Events and implemented the configuration reloading functionality. he's 
also been very active providing input and fixes for many bugs.


as we've been doing, please vote here: 
https://review.openstack.org/#/c/242058/


reviews:
https://review.openstack.org/#/q/reviewer:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z 



patches:
https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z 

https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/python-ceilometerclient,n,z 



cheers,



--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] [Bug#1497073]The return sample body of sample-list is different when use -m and not

[gord chung]

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 8:25 PM, liusheng wrote:
I don't think we need two APIs to act duplicated functionalities, the 
"sample-list -m" command actually invoke API "GET 
/V2/meters/", it is more like a meter related API, not 
sample. I personally prefer to mark the "sample-list -m" command 
deprecated and dropped in future cycle. is this reasonable ?


--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer][vitrage][horizon] ceilometer alarms screen in horizon

[ITZIKOWITZ, Noy (Noy)]

Hi,
Following our Tokyo meetings and chats around vitrage and ceilometer, we are 
now working on vitrage blueprints for Mitaka.
One of the blueprints is around ‘active alarms’ screen in the horizon dashboard.
Is there any open blueprint for that, or should I open a new one?
Was this discussed in the past?
Thanks,
Noy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][vitrage][horizon] ceilometer alarms screen in horizon

[Rob Cresswell (rcresswe)]

This blueprint is being revived by a new assignee I believe: 
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page

Rob

From: "ITZIKOWITZ, Noy (Noy)" 
<noy.itzikow...@alcatel-lucent.com<mailto:noy.itzikow...@alcatel-lucent.com>>
Reply-To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, 8 November 2015 14:03
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [ceilometer][vitrage][horizon] ceilometer alarms 
screen in horizon

Hi,
Following our Tokyo meetings and chats around vitrage and ceilometer, we are 
now working on vitrage blueprints for Mitaka.
One of the blueprints is around ‘active alarms’ screen in the horizon dashboard.
Is there any open blueprint for that, or should I open a new one?
Was this discussed in the past?
Thanks,
Noy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !

[Raghunath D]

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 user's/application's.

We are exploring Ceilometer for this purpose.We came across below blue print 
which is similar to our requirement.

 https://blueprints.launchpad.net/ceilometer/+spec/declarative-notifications.

We have few queries on declarative-notifications frame work,could you please 
help us in addressing them:

1.We are looking for an API for Subcribing/Publishing notification.Do this 
frame work exposes any such API,if yes could you 
   please provide us API doc or spec how to use it.
2.If the frame work doesn't have such API,does any of the development group is 
working in this area.
3.Please suggest what would be the best place in ceilometer notification frame 
work(publisher/dispatcher/..)
   to implement the Subscribe and Publish API.

With Best Regards
Raghunath Dudyala
Tata Consultancy Services Limited
Mailto: raghunat...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !

[gord chung]

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 user's/application's.

We are exploring Ceilometer for this purpose.We came across below blue 
print which is similar to our requirement.


 https://blueprints.launchpad.net/ceilometer/+spec/declarative-notifications.


i'm not exactly clear on what you are trying to achieve. that said, the 
basic premise of the above blueprint is that if serviceX (nova, neutron, 
etc...) starts publishing a new notification with a metric of interest, 
Ceilometer can be easily configured to capture said metric by adding a 
metric definition to a definition file[1] or a custom definition 
file[2]. the same can be done for events[3].




We have few queries on declarative-notifications frame work,could you 
please help us in addressing them:


1.We are looking for an API for Subcribing/Publishing notification.Do 
this frame work exposes any such API,if yes could you

   please provide us API doc or spec how to use it.
2.If the frame work doesn't have such API,does any of the development 
group is working in this area.
3.Please suggest what would be the best place in ceilometer 
notification frame work(publisher/dispatcher/..)

   to implement the Subscribe and Publish API.


from what is described, it seems like you'd like Ceilometer to capture a 
notification and republish it rather than stored in a Ceilometer 
supported storage driver (ie Gnocchi, ElasticSearch, SQL, etc...). 
currently, the only way to do this is to not enable a collector service. 
doing so, the Event/Sample will be published to a message queue 
(default) which you can configure your service to pull from. currently, 
i don't believe oslo.messaging supports pub/sub work flow. 
alternatively, you can use one of the other publishers[4]. the kafka 
publisher should allow you to do a pub/sub type workflow. i know RAX has 
atom hopper[5] which uses atom feeds to support pub/sub functionality. 
there was discussions on adding support for this but no work has been 
done on it. feel free to propose it if you feel it's worthwhile.


[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/notifications.py#L31
[3] 
https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/event_definitions.yaml
[4] 
http://docs.openstack.org/admin-guide-cloud/telemetry-data-retrieval.html#publishers

[5] http://atomhopper.org/

cheers,

--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] [Bug#1497073]The return sample body of sample-list is different when use -m and not

[gord chung]

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 solution is to document that these are different APIs 
and will return different results.


On 05/11/2015 2:30 AM, Lin Juan IX Xia wrote:

Hi,

Here is an open bug : https://bugs.launchpad.net/ceilometer/+bug/1497073

Is it a bug or not?

For the command "ceilometer sample-list --meter cpu", it calls 
"/v2/meter" API and return the OldSample objects
which return body is different from "ceilometer sample-list --query 
'meter=cpu'".
To fix this inconformity, we can deprecate the command using -m or fix 
it to return the same body as command sample-list

Best Regards,
Xia Linjuan




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] [Bug#1497073]The return sample body of sample-list is different when use -m and not

[liusheng]

I don't think we need two APIs to act duplicated functionalities, the 
"sample-list -m" command actually invoke API "GET 
/V2/meters/", it is more like a meter related API, not 
sample. I personally prefer to mark the "sample-list -m" command 
deprecated and dropped in future cycle. is this reasonable ?


在 2015/11/6 6:39, gord chung 写道:
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 solution is to document that these are different APIs 
and will return different results.


On 05/11/2015 2:30 AM, Lin Juan IX Xia wrote:

Hi,

Here is an open bug : https://bugs.launchpad.net/ceilometer/+bug/1497073

Is it a bug or not?

For the command "ceilometer sample-list --meter cpu", it calls 
"/v2/meter" API and return the OldSample objects
which return body is different from "ceilometer sample-list --query 
'meter=cpu'".
To fix this inconformity, we can deprecate the command using -m or 
fix it to return the same body as command sample-list

Best Regards,
Xia Linjuan




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] proposal to add Rohit Jaiswal to Ceilometer core

[ZhiQiang Fan]

+1

On Thu, Nov 5, 2015 at 9:45 PM, 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 many issues with Events
> and implemented the configuration reloading functionality. he's also been
> very active providing input and fixes for many bugs.
>
> as we've been doing, please vote here:
> https://review.openstack.org/#/c/242058/
>
> reviews:
>
> https://review.openstack.org/#/q/reviewer:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z
>
> patches:
>
> https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z
>
> https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/python-ceilometerclient,n,z
>
> cheers,
>
> --
> gord
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] proposal to add Rohit Jaiswal to Ceilometer core

[gord chung]

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 we've been doing, please vote here: 
https://review.openstack.org/#/c/242058/


reviews:
https://review.openstack.org/#/q/reviewer:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z

patches:
https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z
https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/python-ceilometerclient,n,z

cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] [Bug#1497073]The return sample body of sample-list is different when use -m and not

[Lin Juan IX Xia]

Hi,Here is an open bug : https://bugs.launchpad.net/ceilometer/+bug/1497073Is it a bug or not?For the command "ceilometer sample-list --meter cpu", it calls "/v2/meter" API and return the OldSample objectswhich return body is different from "ceilometer sample-list --query 'meter=cpu'".To fix this inconformity, we can deprecate the command using -m or fix it to return the same body as command sample-listBest Regards,Xia Linjuan


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Meeting cancelled for this week

[gord chung]

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 meeting for this week 
in favor of Summit travels and preparation.

We finished to organize our sessions for next week, you can find the schedule 
here: https://mitakadesignsummit.sched.org/overview/type/ceilometer
The etherpads for the sessions are available here: 
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Ceilometer

Best Regards,
Ildikó

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh] proposal to add Ryota Mibu to Aodh core

[gord chung]

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



reviews:
https://review.openstack.org/#/q/reviewer:%22Ryota+MIBU%22+project:openstack/aodh,n,z 



cheers,





--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Meeting cancelled for this week

[Ildikó Váncsa]

Hi All,

I would like to inform you that we cancel the Ceilometer meeting for this week 
in favor of Summit travels and preparation.

We finished to organize our sessions for next week, you can find the schedule 
here: https://mitakadesignsummit.sched.org/overview/type/ceilometer
The etherpads for the sessions are available here: 
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Ceilometer

Best Regards,
Ildikó

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[Srikanth Vavilapalli]

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" and 
"average" fields in statistics query

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 as shown below. I have also 
> verified the samples query for this meter and there are 1544 samples (output 
> shown below) with all of them having value as "150.0". So ideally the "Avg" 
> filed should be "150.0" in this scenario. Could anyone tell me in what 
> scenario we will see these two fields as "inf" in the meter statistics query? 
> Plz let me know if you need more details or logs here. Appreciate your help.
>
> Thanks
> Srikanth
>
>
> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
> statistics --meter=vcpe.dns.cache.size
> ++++---+---+-+-+---++++
> | Period | Period Start   | Period End | Max   | 
> Min   | Avg | Sum | Count | Duration   | Duration Start | 
> Duration End   |
> ++++---+---+-+-+---++++
> | 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
> 150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
> 2015-10-19T17:47:20.587000 |
> ++++---+---+-+-+---++++
>
>
> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
> sample-list --meter=vcpe.dns.cache.size
> +-+-+---++-++
> | Resource ID | Name| Type  | Volume | Unit| Timestamp
>   |
> +-+-+---++-++
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:47:20.587000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:47:00.048000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:42:20.47 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:41:59.921000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:37:20.362000 |
> .
> .
> .
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:50:25.499000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:45:46.255000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:45:25.374000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:40:46.131000 |
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[gord chung]

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 
as shown below. I have also verified the samples query for this meter and there are 1544 samples (output shown below) with all of them having value 
as "150.0". So ideally the "Avg" filed should be "150.0" in this scenario. Could anyone tell me in what scenario we 
will see these two fields as "inf" in the meter statistics query? Plz let me know if you need more details or logs here. Appreciate your 
help.

Thanks
Srikanth


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer statistics 
--meter=vcpe.dns.cache.size
++++---+---+-+-+---++++
| Period | Period Start   | Period End | Max   | 
Min   | Avg | Sum | Count | Duration   | Duration Start | Duration 
End   |
++++---+---+-+-+---++++
| 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
2015-10-19T17:47:20.587000 |
++++---+---+-+-+---++++


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
sample-list --meter=vcpe.dns.cache.size
+-+-+---++-++
| Resource ID | Name| Type  | Volume | Unit| Timestamp  
|
+-+-+---++-++
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:20.587000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:00.048000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:42:20.47 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:41:59.921000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:37:20.362000 |
.
.
.
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:50:25.499000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:46.255000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:25.374000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:40:46.131000 |

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[gord chung]

could you open a bug on 
https://bugs.launchpad.net/ceilometer/+bugs?orderby=-id=0 and 
reference this thread


i would also check to see if ceilometer-api logs have any noticeable 
warning/errors. it's possible a datatype is being restricted there as well.


thanks

On 20/10/2015 12:22 PM, 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" and 
"average" fields in statistics query

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 
as shown below. I have also verified the samples query for this meter and there are 1544 samples (output shown below) with all of them having value 
as "150.0". So ideally the "Avg" filed should be "150.0" in this scenario. Could anyone tell me in what scenario we 
will see these two fields as "inf" in the meter statistics query? Plz let me know if you need more details or logs here. Appreciate your 
help.

Thanks
Srikanth


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer
statistics --meter=vcpe.dns.cache.size
++++---+---+-+-+---++++
| Period | Period Start   | Period End | Max   | 
Min   | Avg | Sum | Count | Duration   | Duration Start | Duration 
End   |
++++---+---+-+-+---++++
| 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
2015-10-19T17:47:20.587000 |
++++---+---+-+-+---++++


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer
sample-list --meter=vcpe.dns.cache.size
+-+-+---++-++
| Resource ID | Name| Type  | Volume | Unit| Timestamp  
|
+-+-+---++-++
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:20.587000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:00.048000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:42:20.47 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:41:59.921000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:37:20.362000 |
.
.
.
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:50:25.499000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:46.255000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:25.374000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:40:46.131000 |

__
 OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[Srikanth Vavilapalli]

I have raised the bug for this 
(https://bugs.launchpad.net/ceilometer/+bug/1508220)

I have checked the ceilometer-api logs when I ran the query and have not found 
any errors or warnings. I could see only the below two logs:

2015-10-20 17:47:06.771 84151 DEBUG ceilometer.api.controllers.v2.meters [-] 
computed value coming from u'(,)' statistics 
/usr/lib/python2.7/dist-packages/ceilometer/api/controllers/v2/meters.py:407
2015-10-20 17:47:06.773 84151 INFO werkzeug [-] 192.168.0.3 - - [20/Oct/2015 
17:47:06] "GET /v2/meters/vcpe.dns.cache.size/statistics HTTP/1.1" 200 -

Thanks
Srikanth



-Original Message-
From: gord chung [mailto:g...@live.ca] 
Sent: Tuesday, October 20, 2015 1:39 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and 
"average" fields in statistics query

could you open a bug on
https://bugs.launchpad.net/ceilometer/+bugs?orderby=-id=0 and reference 
this thread

i would also check to see if ceilometer-api logs have any noticeable 
warning/errors. it's possible a datatype is being restricted there as well.

thanks

On 20/10/2015 12:22 PM, 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" 
> and "average" fields in statistics query
>
> 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 as shown below. I have also 
>> verified the samples query for this meter and there are 1544 samples (output 
>> shown below) with all of them having value as "150.0". So ideally the "Avg" 
>> filed should be "150.0" in this scenario. Could anyone tell me in what 
>> scenario we will see these two fields as "inf" in the meter statistics 
>> query? Plz let me know if you need more details or logs here. Appreciate 
>> your help.
>>
>> Thanks
>> Srikanth
>>
>>
>> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
>> statistics --meter=vcpe.dns.cache.size
>> ++++---+---+-+-+---++++
>> | Period | Period Start   | Period End | Max   | 
>> Min   | Avg | Sum | Count | Duration   | Duration Start | 
>> Duration End   |
>> ++++---+---+-+-+---++++
>> | 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
>> 150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
>> 2015-10-19T17:47:20.587000 |
>> ++++---+---+-+-+---++++
>>
>>
>> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
>> sample-list --meter=vcpe.dns.cache.size
>> +-+-+---++-++
>> | Resource ID | Name| Type  | Volume | Unit| Timestamp   
>>|
>> +-+-+---++-++
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:47:20.587000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:47:00.048000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:42:20.47 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:41:59.921000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:37:20.362000 |
>> .
>> .
>> .
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-17T01:50:25.499000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-17T01:45:46.255000 |
>> |

[openstack-dev] [ceilometer] ceilometer+ops session

[gord chung]

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 
might be worth your time to join as well.


as discussed, we'll be using our ceilometer contributor meet up time to 
discussion the results and feedback from surveys.


[1] 
https://mitakadesignsummit.sched.org/event/2b7a39ba370a9c9f7ab8b7de57ca6188
[2] 
https://mitakadesignsummit.sched.org/event/f72ce4bf2d403aec3357b3af2492ead2


cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[Srikanth Vavilapalli]

Hi

I have observed "inf" values for "sum" and "average" fields in a ceilometer 
statistics query on one of my custom meter as shown below. I have also verified 
the samples query for this meter and there are 1544 samples (output shown 
below) with all of them having value as "150.0". So ideally the "Avg" filed 
should be "150.0" in this scenario. Could anyone tell me in what scenario we 
will see these two fields as "inf" in the meter statistics query? Plz let me 
know if you need more details or logs here. Appreciate your help. 

Thanks
Srikanth


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer statistics 
--meter=vcpe.dns.cache.size
++++---+---+-+-+---++++
| Period | Period Start   | Period End | Max   | 
Min   | Avg | Sum | Count | Duration   | Duration Start | Duration 
End   |
++++---+---+-+-+---++++
| 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
2015-10-19T17:47:20.587000 |
++++---+---+-+-+---++++


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
sample-list --meter=vcpe.dns.cache.size
+-+-+---++-++
| Resource ID | Name| Type  | Volume | Unit| Timestamp  
|
+-+-+---++-++
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:20.587000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:00.048000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:42:20.47 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:41:59.921000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:37:20.362000 |
.
.
.
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:50:25.499000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:46.255000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:25.374000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:40:46.131000 |

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer][aodh] proposal to add Ryota Mibu to Aodh core

[gord chung]

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

reviews:
https://review.openstack.org/#/q/reviewer:%22Ryota+MIBU%22+project:openstack/aodh,n,z

cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh] proposal to add Ryota Mibu to Aodh core

[gord chung]

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



reviews:
https://review.openstack.org/#/q/reviewer:%22Ryota+MIBU%22+project:openstack/aodh,n,z 



cheers,



--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer][horizon] tentative design summit schedule

[gord chung]

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 any conflicts to work around.

[1] https://mitakadesignsummit.sched.org/overview/type/ceilometer

cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Meter-list with multiple filters in simple query is not working

[Eoghan Glynn]

> Hi
> 
> Can anyone plz help me on how to specify a simple query with multiple values
> for a query field in a Ceilometer meter-list request? I need to fetch meters
> that belongs to more than one project id. I have tried the following query
> format, but only the last query value (in this case, project_id=
> d41cdd2ade394e599b40b9b50d9cd623) is used for filtering. Any help is
> appreciated here.
> 
> curl -H 'X-Auth-Token:'
> http://localhost:8777/v2/meters?q.field=project_id=eq=f28d2e522e1f466a95194c10869acd0c=project_id=eq=d41cdd2ade394e599b40b9b50d9cd623
> 
> Thanks
> Srikanth

By "not working" you mean "not doing what you (incorrectly) expect it to do"

Your query asks for samples with aproject_id set to *both* f28d.. *and* d41c..
The result is empty, as a sample can't be associated with two project_ids.

The ceilometer simple query API combines all filters using logical AND.

Seems like you want logical OR here, which is possible to express via complex
queries:

  http://docs.openstack.org/developer/ceilometer/webapi/v2.html#complex-query

Cheers,
Eoghan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Meter-list with multiple filters in simple query is not working

[Srikanth Vavilapalli]

Hi 

Thanks for your reply. 

Yes, I need the logical OR operation here. 

Seems the simple query is not either doing logical "AND" operation also. 
Because, if so, the output should be empty list in my example. However, the 
output is list of meters with the project_id value as d41cd...*. If I 
interchange the project_id field values in my query, the resulting output is 
list of meters with the project_id value as f28d2...*. i.e. the API is using 
the last q.field value for filtering for the "project_id" field.

I have seen the complex query format supporting these additional operations 
like logical "OR", but my understanding from the documentation was that these 
complex queries are supported only for Samples, Alarms and Alarms History, but 
not for "Meters". Nevertheless I still tried this complex query with /v2/meters 
by following /v2/query/samples example and it was returning 404 Not found. Plz 
correct me if I am doing something wrong here.

curl -X POST -H 'X-Auth-Token:eed134b917914fd987e50d8ec1651213' -H 
'Content-Type: application/json' -d '{"filter" : "{\"or\":[{\"=\": 
{\"project_id\": \"f28d2e522e1f466a95194c10869acd0c\"}},{\"=\": 
{\"project_id\": \"d41cdd2ade394e599b40b9b50d9cd623\"}}]}}' 
"http://10.11.10.1:8777/v2/query/meters;

Thanks
Srikanth
  

-Original Message-
From: Eoghan Glynn [mailto:egl...@redhat.com] 
Sent: Monday, October 12, 2015 4:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Meter-list with multiple filters in 
simple query is not working



> Hi
> 
> Can anyone plz help me on how to specify a simple query with multiple 
> values for a query field in a Ceilometer meter-list request? I need to 
> fetch meters that belongs to more than one project id. I have tried 
> the following query format, but only the last query value (in this 
> case, project_id=
> d41cdd2ade394e599b40b9b50d9cd623) is used for filtering. Any help is 
> appreciated here.
> 
> curl -H 'X-Auth-Token:'
> http://localhost:8777/v2/meters?q.field=project_id=eq=f28
> d2e522e1f466a95194c10869acd0c=project_id=eq=d41cd
> d2ade394e599b40b9b50d9cd623
> 
> Thanks
> Srikanth

By "not working" you mean "not doing what you (incorrectly) expect it to do"

Your query asks for samples with aproject_id set to *both* f28d.. *and* d41c..
The result is empty, as a sample can't be associated with two project_ids.

The ceilometer simple query API combines all filters using logical AND.

Seems like you want logical OR here, which is possible to express via complex
queries:

  http://docs.openstack.org/developer/ceilometer/webapi/v2.html#complex-query

Cheers,
Eoghan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Meter-list with multiple filters in simple query is not working

[Srikanth Vavilapalli]

Hi

Can anyone plz help me on how to specify a simple query with multiple values 
for a query field in a Ceilometer meter-list request? I need to fetch meters 
that belongs to more than one project id. I have tried the following query 
format, but only the last query value (in this case, project_id= 
d41cdd2ade394e599b40b9b50d9cd623) is used for filtering. Any help is 
appreciated here.

curl -H 'X-Auth-Token:' 
http://localhost:8777/v2/meters?q.field=project_id=eq=f28d2e522e1f466a95194c10869acd0c=project_id=eq=d41cdd2ade394e599b40b9b50d9cd623

Thanks
Srikanth
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Ceilometer, New measurements, Types

[phot...@126.com]

Meters are measurable value. So it cannot be a string.

If you really need to have notifications about event that is exist but
cannot be measured you can use Events.

http://docs.openstack.org/admin-guide-cloud/telemetry-events.html

Cheers,

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Sat, Oct 10, 2015 at 6:19 AM, phot...@126.com  wrote:

> There are three type of meters are defined in Ceilometer, including
> Cumulative, Gauge, Delta.
> In fact, these three types are numeric, but i need string.
> How could i make ceilometer to support string.
>
> Doc: http://docs.openstack.org/developer/ceilometer/new_meters.html
> image:
> --
> phot...@126.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Ceilometer, New measurements, Types

[Igor Degtiarov]

Meters are measurable value. So it cannot be a string.

If you really need to have notifications about event that is exist but
cannot be measured you can use Events.

http://docs.openstack.org/admin-guide-cloud/telemetry-events.html

Cheers,

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Sat, Oct 10, 2015 at 6:19 AM, phot...@126.com  wrote:

> There are three type of meters are defined in Ceilometer, including
> Cumulative, Gauge, Delta.
> In fact, these three types are numeric, but i need string.
> How could i make ceilometer to support string.
>
> Doc: http://docs.openstack.org/developer/ceilometer/new_meters.html
> image:
> --
> phot...@126.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] Inconsistent timestamping of polled data

[Wen Zhi WW Yu]

Hi all,

As Gordon descriped in https://bugs.launchpad.net/ceilometer/+bug/1491509 ,
many of pollsters define the timestamp individually for each sample that is
generated rather than basing on when the data was polled. I agree with
Gordon on that the timestamping of samples should base on when the data was
polled.

What's your opinion on this?

Best Regards,
Yu WenZhi(余文治）
OpenStack on Power Development, IBM Shanghai
2F, 399 Keyuan Rd, Zhangjiang Chuangxin No. 10 Building, Zhangjiang High
Tech Park Shanghai
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Ceilometer, New measurements, Types

[phot...@126.com]

There are three type of meters are defined in Ceilometer, including Cumulative, 
Gauge, Delta. 
In fact, these three types are numeric, but i need string.
How could i make ceilometer to support string.

Doc: http://docs.openstack.org/developer/ceilometer/new_meters.html
image: 


phot...@126.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Inconsistent timestamping of polled data

[Igor Degtiarov]

Hi!

Looks good to me, especially for cases when after some incident we gather a
great amount of notifications in queue and stated to work with it so some
data will have incorrect timestamp if it set only when sample is created.

Cheers,

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Fri, Oct 9, 2015 at 1:00 PM, Wen Zhi WW Yu  wrote:

> Hi all,
>
> As Gordon descriped in https://bugs.launchpad.net/ceilometer/+bug/1491509
> , many of pollsters define the timestamp individually for each sample that
> is generated rather than basing on when the data was polled. I agree with
> Gordon on that the timestamping of samples should base on when the data was
> polled.
>
> What's your opinion on this?
>
> Best Regards,
> Yu WenZhi(余文治）
> OpenStack on Power Development, IBM Shanghai
> 2F, 399 Keyuan Rd, Zhangjiang Chuangxin No. 10 Building, Zhangjiang High
> Tech Park Shanghai
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] external projects extending ceilometer

[gord chung]

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, i've added a 
section in the wiki[1] so there's a place for users to see what 
extensions exists and for developers to promote their customisations. 
feel free to add your own projects.


[1] https://wiki.openstack.org/wiki/Ceilometer#Ceilometer_Extensions

cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer][aodh][gnocchi] Tokyo design session planning

[gord chung]

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,

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 other 
monitoring/metering/alarming related project.


official proposals can be submitted here: 
https://docs.google.com/spreadsheets/d/1ea_P2k1kNy_SILEnC-5Zl61IFhqEOrlZ5L8VY4-xNB0/edit?usp=sharing


we've also created an etherpad for those wishing to brainstorm ideas 
before adding formal proposal: 
https://etherpad.openstack.org/p/tokyo-ceilometer-design-summit


we have tentatively set submission deadline for October 5, 2015, which 
will be followed by a public vote.


cheers,
--
gord


--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Capturing isolated events

[Sachin Manpathak]

Can ceilometer-gurus advise?

[For Ceilometer/Juno]
Use case:
catch instance creation error notifications with ceilometer.

I tried the notifications as well as metering route, but haven't quite
figured out how to do this --

- Added a notification class to ceilometer
/
compute

/notifications

/instance.py

- Noticed that there is a class called "Instance" which already subscribes
to events compute.instance.*, disabled that by removing it from the egg
entry points (setup.cfg)
- Created a pipeline to define a meter for my notifications class.

I noticed that the ceilometer-agent-notification service does not consume
any notifications with above changes. I had to set
store_events=true in ceilometer.conf

Now, ceilometer generates events, but they are generic type.

1. Should I change event_definitions.yaml to store event information in the
format that I want?
2. a way to generate only the event I am interested in, not all by default.


Thanks,
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] OpenStack Telemetry user survey

[gord chung]

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 ensure that you ask someone 
within your organization that is hands on using Ceilometer.


https://goo.gl/rKNhM1

On behalf of the Ceilometer community, we thank you for the time you 
will spend in helping us understand your needs.


--
Gordon Chung
Ceilometer PTL

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] How to enable devstack plugins

[Zhai, Edwin]

Chris,
Thanks for clarification.


On Tue, 15 Sep 2015, Chris Dent wrote:


On Tue, 15 Sep 2015, Zhai, Edwin wrote:

I saw some patches from Chris Dent to enable functions in devstack/*. But 
it conflicts with devstack upstream so that start each ceilometer service 
twice. Is there any official way to setup ceilometer as devstack plugin?


What I've been doing is checking out the devstack branch associated
with this review that removes ceilometer from devstack [1] (with a
`git review -d 196383`) and then stacking from there. It's cumbersome
but gets the job done.

This pain point should go away very soon. We've just been waiting on
the necessary infra changes to get various jobs that use ceilometer
prepared to use the ceilometer devstack plugin[2]. I think that's
ready to go now so we ought to see that merge soon.

[1] https://review.openstack.org/#/c/196383/
[2] https://review.openstack.org/#/c/196446/ and dependent reviews.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Best Rgds,
Edwin

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] how to get current memory utilization of an instance

[gord chung]

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] 
https://github.com/openstack/ceilometer-specs/blob/master/specs/kilo/libvirt-memory-utilization-inspector.rst#dependencies



cheers,

On 16/09/2015 6:23 AM, Abhishek Talwar wrote:

Hi Folks,



I have an OpenStack kilo setup and I am trying to get the memory usage 
of the instances created in it.


I researched and found that ceilometer has a meter called 
"memory.usage" that can give us the memory utilization of an instance. 
However, on doing ceilometer meter-list it does not list 
"memory.usage" as a meter. After searching I found that this problem 
is being faced by many contributors and a possible solution is 
changing nova configurations that does not help.


So can you help me with some other possible solution that can help me 
in finding an instance's current memory utilization. I am working with 
something that would require getting the memory and disk utilization.


Please provide a solution for this.

Thanks and Regards

Abhishek Talwar

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] ceilometer code debugging

[gord chung]

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 functionality. you might find some useful information in the 
dev docs[1] if you have questions about Ceilometer. if it's a pydev 
specific question you might want to generalise your subject line to have 
more eyes.


[1] http://docs.openstack.org/developer/ceilometer


On 16/09/15 08:42 AM, Nanda Devi Sahu wrote:

Hello,

I am trying to debug Ceilometer code taken from git. I have configured 
Eclipse with Pydev for the same. The configuration seems to be fine 
but when I do a debug of the code it shows to be running but I do not 
see the flow of the code. LIke the main thread and the following threads.


Attached is the debug prespective view where the run is working 
without any code stack.


Could you please suggest what Am I missing to get the flow. I have 
also attached the debug configuration image for reference.



Regards,
Nanda.

*L Technology Services Ltd*

www.LntTechservices.com 

This Email may contain confidential or privileged information for the 
intended recipient (s). If you are not the intended recipient, please 
do not use or disseminate the information, notify the sender and 
delete it from your system.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] How to enable devstack plugins

[Chris Dent]

On Tue, 15 Sep 2015, Zhai, Edwin wrote:

I saw some patches from Chris Dent to enable functions in devstack/*. But it 
conflicts with devstack upstream so that start each ceilometer service twice. 
Is there any official way to setup ceilometer as devstack plugin?


What I've been doing is checking out the devstack branch associated
with this review that removes ceilometer from devstack [1] (with a
`git review -d 196383`) and then stacking from there. It's cumbersome
but gets the job done.

This pain point should go away very soon. We've just been waiting on
the necessary infra changes to get various jobs that use ceilometer
prepared to use the ceilometer devstack plugin[2]. I think that's
ready to go now so we ought to see that merge soon.

[1] https://review.openstack.org/#/c/196383/
[2] https://review.openstack.org/#/c/196446/ and dependent reviews.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] PTL candidacy

[gord chung]

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 
previously, we have a diverse set of contributors from across the globe 
working on various aspects of metering and monitoring and it is my goal 
to ensure nothing slows them down (myself included).


that said, as we look forward to Mitaka, i hope to follow along the path 
of stability, simplicity and usability. some items i'd like to target are:


- rolling upgrades - having a fluid upgrade path for operators is 
critical to providing a highly available cloud environment for their 
users. i would like to have a viable solution in Ceilometer that can 
provide this functionality with zero/minimal performance degradation.


- building up events - we started work on adding inline event alarming 
in Aodh during Liberty, this is something i'd like to improve upon by 
adding multiple worker support and broader alarming evaluations. also, a 
common use case for events is to analyse the data for BI. while we allow 
the ability to query and alarm on events. one useful tool would be the 
ability to run statistics on events such as the number of instances 
launched.


- optimising collection - we improved ease of use by adding declarative 
notification support in Liberty. it'd be great if this work could be 
adopted by projects producing metrics. additionally, we currently have a 
extremely tight coupling between resource metadata and measurement data. 
i'd like to evaluate how to loosen this so our data collection and 
storage is more flexible.


- continuing the refactoring - removing deprecated/redundant 
functionality; it was nice deprecating/deleting stuff, let's keep doing 
it (within reason)! one possible target would be splitting storage/api, 
while starting the initial deprecation of v2 metering api.


- functional and integration testing -  we now have integration and 
functional test living within our repositories. this should allow us to 
develop testing easier so it'd be good to broaden the coverage.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-April/060536.html


cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Ceilometer M Midcycle

[gord chung]

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 of 
meeting face to face for a ceilometer midcycle in Dublin, IE. We'd 
like to gather for three days to discuss all the work we are currently 
doing; however, we have access to space for 5 so you could also use 
that space for co working outside of the meeting dates.  We have two 
date polls: one for Nov 30-Dec 18 at 
http://doodle.com/poll/hmukqwzvq7b54cef, and one for Jan 11-22 at 
http://doodle.com/poll/kbkmk5v2vass249i. You can vote for any of the 
days in there that work for you.  If we don't get enough interest in 
either poll, we will do a virtual midcycle like we did last year.  
Please vote for your favorite days in the two polls if you are 
interested in attending in person. If we don't get many votes, we'll 
circulate another poll for the virtual dates.


--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Ceilometer M Midcycle

[Jason Myers]

Hello Everyone,
We are setting up a few polls to determine the possibility of 
meeting face to face for a ceilometer midcycle in Dublin, IE. We'd like 
to gather for three days to discuss all the work we are currently doing; 
however, we have access to space for 5 so you could also use that space 
for co working outside of the meeting dates.  We have two date polls: 
one for Nov 30-Dec 18 at http://doodle.com/poll/hmukqwzvq7b54cef, and 
one for Jan 11-22 at http://doodle.com/poll/kbkmk5v2vass249i.  You can 
vote for any of the days in there that work for you.  If we don't get 
enough interest in either poll, we will do a virtual midcycle like we 
did last year.  Please vote for your favorite days in the two polls if 
you are interested in attending in person. If we don't get many votes, 
we'll circulate another poll for the virtual dates.


Cheers,
Jason Myers
--
Sent from Postbox 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] How to enable devstack plugins

[Zhai, Edwin]

All,
I saw some patches from Chris Dent to enable functions in devstack/*. But it 
conflicts with devstack upstream so that start each ceilometer service twice. Is 
there any official way to setup ceilometer as devstack plugin?


Best Rgds,
Edwin

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Gnocchi]Gnocchi cannot deal with combined resource-id ?

[Luo Gangyi]

>  I was talking about that:

>   
> https://git.openstack.org/cgit/openstack/ceilometer/tree/etc/ceilometer/gnocchi_resources.yaml#n67

 I check it again, it seems gnocchin_resouces.yaml was updated on Sep 1, 2015, 
and my Ceilometer code is not
 updated. 
 Thanks Julien.
  --
 Luo Gangyi   luogan...@cmss.chinamobile.com



  
  

 

 -- Original --
  From:  "Julien Danjou";<jul...@danjou.info>;
 Date:  Sat, Sep 12, 2015 10:54 PM
 To:  "Luo Gangyi"<lgy...@foxmail.com>; 
 Cc:  "OpenStack Development Mailing L"<openstack-dev@lists.openstack.org>; 
 Subject:  Re: ?? [openstack-dev] [Ceilometer][Gnocchi]Gnocchi cannot deal 
with combined resource-id ?

 

On Sat, Sep 12 2015, Luo Gangyi wrote:

>  I checked it again, no "ignored" is marked, seems the bug of devstack ;(

I was talking about that:

  
https://git.openstack.org/cgit/openstack/ceilometer/tree/etc/ceilometer/gnocchi_resources.yaml#n67

>  And it's OK that gnocchi is not perfect now, but I still have some worries 
> about how gnocchi deal with or going to deal with instance--tapxxx 
> condition.
>  I see 'network.incoming.bytes' belongs to resouce type 'instance'.
>  But no attributes of instance can save the infomation of tap name.
>  Although I can search
>  all metric ids from resouce id(instance uuid), how do I distinguish them 
> from different taps of an instance?

Where do you see network.incoming.bytes as being linked to an instance?
Reading gnocchi_resources.yaml I don't see that.

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer]heavy time cost of event-list

[liusheng]

Hi folks,

With the master Ceilometer installed, and use mysql backend, the 
event-list command met a heavy time cost.  if we have a bit large number 
of events stored, it is easy to cause event list API request timeout, 
the rally people told me that this issue has broken the 
gate-rally-dsvm-rally job, see[1], there is a bug they reported to track 
this[3]. As we konw, the admin roled uers can only query thire own 
events(the project trait value can match the project id) and events 
without project_id trait, this is implemented in event-rbac feature[2], 
before this change, the job is OK. maybe we have mistake in sql query ? 
I will dig more.


FYI, some testing infomation in my devstack environment:

root@szxbzci0007:/opt/stack/ceilometer# time ceilometer event-list |wc -l
109

real0m51.780s
user0m0.354s
sys0m0.060s


mysql> select count(*) from event;
+--+
| count(*) |
+--+
| 1540 |
+--+
1 row in set (0.00 sec)

mysql> select count(*) from trait_text;
+--+
| count(*) |
+--+
| 3097 |
+--+
1 row in set (0.01 sec)


[1] 
http://logs.openstack.org/35/222435/1/check/gate-rally-dsvm-rally/aa38d0f/rally-plot/results.html.gz#/CeilometerEvents.create_user_and_get_event/failures

[1] https://review.openstack.org/#/c/218706/
[2] https://bugs.launchpad.net/ceilometer/+bug/1494440

Best regards
Liu sheng



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Chris Dent]

On Fri, 11 Sep 2015, Luo Gangyi wrote:


I am using master branch and newest code for testing.

For the purpose for learning the structure of gnocchi, I changed the
default UUID type of mysql from binary to char, so I can easily link
the resource-id(I mean in database), metric id and directory name of
storing measures.

When I did that, I found all the metrics where their resource id is
combined(here, I mean in Ceilometer, such as instance-xxx-tap)
have no measures stored.


In addition to the things that Julien has said, one thing that is
non-obvious about how gnocchi stores resources is that if the
incoming ID is _not_ a UUID then a uuid5 hash is created based on the id
provided. So if your resource has an ceilometer-side id of 'instance-xxx-
tap' it will be saved in the database in a form like 
5B0A4989-44C3-46D1-A1ED-
4705062F51A2. The code review for that change is here:
https://review.openstack.org/#/c/216390/

With that change in place you can still use the 'instance-xxx-tap' ID
in the  part of /v1/metric/resource// URLs and in
search queries.

But as pointed out elsewhere in the thread at least some of your
resources are missing because of the 'display_name' attribute being
dropped.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] ?????? [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Luo Gangyi]

Thanks Julien :)
  
 >  But I don't think Ceilometer has this metric posted to Gnocchi yet, the
>  code is a bit young and not finished on the Ceilometer side. If you
>  check gnocchi_resources.yaml, it's still marked "ignored" for now.
  
 I checked it again, no "ignored" is marked, seems the bug of devstack ;(
  
 And it's OK that gnocchi is not perfect now, but I still have some worries 
about how gnocchi deal with or going to deal with instance--tapxxx 
condition.
 I see 'network.incoming.bytes' belongs to resouce type 'instance'. But no 
attributes of instance can save the infomation of tap name. Although I can 
search
 all metric ids from resouce id(instance uuid), how do I distinguish them from 
different taps of an instance?
  --
 Luo Gangyi   luogan...@cmss.chinamobile.com



  
  

 

 --  --
  ??: "Julien Danjou";<jul...@danjou.info>;
 : 2015??9??12??(??) 0:01
 ??: "Luo Gangyi"<lgy...@foxmail.com>; 
 : "OpenStack Development Mailing L"<openstack-dev@lists.openstack.org>; 
 : Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with 
combined resource-id ?

 

On Fri, Sep 11 2015, Luo Gangyi wrote:

Hi Gangyi,

>  I am using master branch and newest code for testing.

Cool.

>  For the purpose for learning the structure of gnocchi, I changed the
>  default UUID type of mysql from binary to char, so I can easily link
>  the resource-id(I mean in database), metric id and directory name of
>  storing measures.

Bah, don't do that ?C and rather use PostgreSQL, it's the recommended
backend. :)

>  When I did that, I found all the metrics where their resource id is
>  combined(here, I mean in Ceilometer, such as instance-xxx-tap)
>  have no measures stored.


>  Log in Ceilometer collector records this:
>  "
>  2015-09-11 07:55:55.097 10636 ERROR ceilometer.dispatcher.gnocchi [-] 
> Resource 
> instance-0001-4641f59e-994c-4255-b0ec-43a276d1c19c-tap8aadb7ad-d7 
> creation failed with status: 400: 
>  
>   400 Bad Request
>  
>  
>   400 Bad Request
>   The server could not comply with the request since it is either malformed 
> or otherwise incorrect.
> Invalid input: required key not provided @ data['display_name']
>   
> 
>
>  "
>  So I wander whether gnocchi cannot deal with such combined resource-id 
> metrics or whether it is because I change the UUID type or whatever.

Yes, it can, but the problem is more likely in the Ceilometer collector
dispatcher code that is sending the data. From the error you have, it
seems it tries to create an instance but it has no value for
display_name, so it is denied by Gnocchi. If this is from a standard
devstack installation, I'd suggest to open a bug on Ceilometer.

>  And another question is how to query measures for those metrics whose
>  resource id is combined.

They are resource on their own so if you know their id you can just
access the metrics at /v1/resources///metric//measures.

>  For example, I want to query the network traffic of an vm, I know the
>  instance uuid -, I know metric name
>  'network.incoming.byte.rate' but I do not know the exact resouce_id
>  and metric id. What procedure should I do ?

You need to know the ID of the resource and then ask for its metric on
the REST interface. If you don't know the ID of the resource, you can
search for it by instance id.

But I don't think Ceilometer has this metric posted to Gnocchi yet, the
code is a bit young and not finished on the Ceilometer side. If you
check gnocchi_resources.yaml, it's still marked "ignored" for now.

-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Luo Gangyi]

Hi devs,


I am trying Ceilometer with gnocchi. 


I find that gnocchi cannot deal with combined resource-id such as 
instance-xx-tapxx or instance--vda. I'm not sure whether it is my 
configuration problem or just bug.


And if such combined resource-id can be processed correctly, what about its 
metadata(or called attributes)? In current design, gnocchi seems treat 
instance-aaa, instance-aaa-tap111,   instance-aaa-tap222 as equal although they 
have parent-child relationship and share many attributes.


Is anyone else have the same problem and concern?



--
Luo gangyiluogan...@chinamobile.com__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] using entry_points for configuration considered harmful

[Chris Dent]

Several weeks ago I made a little tool call pollman[1] that demonstrates
pollsters plugins that are outside the ceilometer python namespace. I
was going to use it in my portion of a summit talk to show just how
incredibly easy it is to create custom pollsters. After getting the
basics working and testing it out I forgot all about it until reminded
about it in a way that I think demonstrates a fairly significant problem
in the way that ceilometer (and perhaps other OpenStack projects) manage
extensions.

Ceilometer is now frozen for Liberty so I've been doing a lot of
devstack runs to find and fix bugs. And what do I spy with my little
cli but:

$ ceilometer meter-list
[...]
| weather.temperature  | gauge  | C  | 2172797  | pollman | pollman |

$ ceilometer sample-list -q resource_id=2172797 --limit 1
[...]
| 0b667812-586a-11e5-9568-3417ebd4f75d | 2172797 | weather.temperature 
| gauge | 18.62  | C| 2015-09-11T09:46:58.571000 |

It's 18.62 C in Newquay today. Good to know.

I have not configured Ceilometer to do this. Pollman set
entry_points on ceilometer months ago and they are being used today.

This is really weird to me. I know why it is happening; it is the
designed in behavior that ceilometer pollsters will activate and run all
available pollster plugins (even when there are not resources available)
but goodness me that's not very explicit.

If I want this to stop the most direct thing to do is uninstall pollman.

Sure, I can disable the meters associated with pollman in
pipeline.yaml but to do I've got to go find out what they are. One
way to do that is to go look at the entry_points, but if I've got
multiple external plugins those entry_points are all over the place.
Not very friendly.

I like entry_points, especially in the way that they allow external
extensions (let's have more of them please!), but we shouldn't be
using them as service configuration[2].

What ideas do people have for being more explicit?

Now that the pollsters are only using the first half of the
pipeline.yaml file it probably makes sense to explore (in Mitaka) a more
explicit polling configuration file, separate from the transformations
described by the pipeline.

[1] https://github.com/cdent/pollman
It gets the temperature for configured locations and saves it as a
sample. Its unfinished because I promptly forgot about it until
reminded as described above.

[2] Yes, I'm conscious of the fact that this problem goes away if I
always use clean installs or virtualenvs but is that something we
always want to require? It would be handy to be able to have a
generic vm image which is "the ceilometer polling machine" and has
all the pollsters installed but not all started by default.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Julien Danjou]

On Fri, Sep 11 2015, Julien Danjou wrote:

> Which version are you testing? The master branch has no support for

s/no/now/

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Julien Danjou]

On Fri, Sep 11 2015, Luo Gangyi wrote:

Hi Luo,

> I find that gnocchi cannot deal with combined resource-id such as
> instance-xx-tapxx or instance--vda. I'm not sure whether it is my
> configuration problem or just bug.

Which version are you testing? The master branch has no support for
resource ID that are not UUID.

> And if such combined resource-id can be processed correctly, what about its
> metadata(or called attributes)? In current design, gnocchi seems treat
> instance-aaa, instance-aaa-tap111, instance-aaa-tap222 as equal although they
> have parent-child relationship and share many attributes.

We just merged support for those resources. We do not store any
attribute other than the name and parent instance AFAICS. What do you
miss as an attribute exactly?

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] using entry_points for configuration considered harmful

[Doug Hellmann]

Excerpts from Chris Dent's message of 2015-09-11 11:31:07 +0100:
> 
> Several weeks ago I made a little tool call pollman[1] that demonstrates
> pollsters plugins that are outside the ceilometer python namespace. I
> was going to use it in my portion of a summit talk to show just how
> incredibly easy it is to create custom pollsters. After getting the
> basics working and testing it out I forgot all about it until reminded
> about it in a way that I think demonstrates a fairly significant problem
> in the way that ceilometer (and perhaps other OpenStack projects) manage
> extensions.
> 
> Ceilometer is now frozen for Liberty so I've been doing a lot of
> devstack runs to find and fix bugs. And what do I spy with my little
> cli but:
> 
>  $ ceilometer meter-list
>  [...]
>  | weather.temperature  | gauge  | C  | 2172797  | pollman | pollman |
> 
>  $ ceilometer sample-list -q resource_id=2172797 --limit 1
>  [...]
>  | 0b667812-586a-11e5-9568-3417ebd4f75d | 2172797 | 
> weather.temperature | gauge | 18.62  | C| 2015-09-11T09:46:58.571000 |
> 
> It's 18.62 C in Newquay today. Good to know.
> 
> I have not configured Ceilometer to do this. Pollman set
> entry_points on ceilometer months ago and they are being used today.
> 
> This is really weird to me. I know why it is happening; it is the
> designed in behavior that ceilometer pollsters will activate and run all
> available pollster plugins (even when there are not resources available)
> but goodness me that's not very explicit.
> 
> If I want this to stop the most direct thing to do is uninstall pollman.
> 
> Sure, I can disable the meters associated with pollman in
> pipeline.yaml but to do I've got to go find out what they are. One
> way to do that is to go look at the entry_points, but if I've got
> multiple external plugins those entry_points are all over the place.
> Not very friendly.

How about making a tool to discover them? Something like
https://pypi.python.org/pypi/entry_point_inspector but more specific to
ceilometer plugins.

> 
> I like entry_points, especially in the way that they allow external
> extensions (let's have more of them please!), but we shouldn't be
> using them as service configuration[2].
> 
> What ideas do people have for being more explicit?

Are the plugins grouped in any way or named to allow wildcards for
partial names? For example, is it easy to say "I want all of the
compute pollsters, but I don't know their names" by using putting
something like 'compute:*' in the configuration file?

> 
> Now that the pollsters are only using the first half of the
> pipeline.yaml file it probably makes sense to explore (in Mitaka) a more
> explicit polling configuration file, separate from the transformations
> described by the pipeline.

That may make sense.

> 
> [1] https://github.com/cdent/pollman
> It gets the temperature for configured locations and saves it as a
> sample. Its unfinished because I promptly forgot about it until
> reminded as described above.
> 
> [2] Yes, I'm conscious of the fact that this problem goes away if I
> always use clean installs or virtualenvs but is that something we
> always want to require? It would be handy to be able to have a
> generic vm image which is "the ceilometer polling machine" and has
> all the pollsters installed but not all started by default.

I think the decision was based on the idea that we didn't expect real
deployments to install packages they weren't using. A dev environment is
obviously a different case.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Luo Gangyi]

Hi, Julien
  
 I am using master branch and newest code for testing.
  
 For the purpose for learning the structure of gnocchi, I changed the default 
UUID type of mysql from binary to char, so I can easily link the resource-id(I 
mean in database), metric id and directory name of storing measures.
  
 When I did that, I found all the metrics where their resource id is 
combined(here, I mean in Ceilometer, such as instance-xxx-tap) have no 
measures stored.
  
 Log in Ceilometer collector records this:
 "
 2015-09-11 07:55:55.097 10636 ERROR ceilometer.dispatcher.gnocchi [-] Resource 
instance-0001-4641f59e-994c-4255-b0ec-43a276d1c19c-tap8aadb7ad-d7 creation 
failed with status: 400: 
 
  400 Bad Request
 
 
  400 Bad Request
  The server could not comply with the request since it is either malformed or 
otherwise incorrect.
Invalid input: required key not provided @ data['display_name']
  


 "
 So I wander whether gnocchi cannot deal with such combined resource-id metrics 
or whether it is because I change the UUID type or whatever.
  
 And another question is how to query measures for those metrics whose resource 
id is combined.
  
 For example, I want to query the network traffic of an vm, I know the instance 
uuid -, I know metric name 'network.incoming.byte.rate' but I do not 
know the exact resouce_id and metric id. What procedure should I do ? 
  --
 Luo Gangyi   luogan...@cmss.chinamobile.com



  
  

 

 -- Original --
  From:  "Julien Danjou";<jul...@danjou.info>;
 Date:  Fri, Sep 11, 2015 06:31 PM
 To:  "Luo Gangyi"<lgy...@foxmail.com>; 
 Cc:  "OpenStack Development Mailing L"<openstack-dev@lists.openstack.org>; 
 Subject:  Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with 
combined resource-id ?

 

On Fri, Sep 11 2015, Luo Gangyi wrote:

Hi Luo,

> I find that gnocchi cannot deal with combined resource-id such as
> instance-xx-tapxx or instance--vda. I'm not sure whether it is my
> configuration problem or just bug.

Which version are you testing? The master branch has no support for
resource ID that are not UUID.

> And if such combined resource-id can be processed correctly, what about its
> metadata(or called attributes)? In current design, gnocchi seems treat
> instance-aaa, instance-aaa-tap111, instance-aaa-tap222 as equal although they
> have parent-child relationship and share many attributes.

We just merged support for those resources. We do not store any
attribute other than the name and parent instance AFAICS. What do you
miss as an attribute exactly?

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

[Julien Danjou]

On Fri, Sep 11 2015, Luo Gangyi wrote:

Hi Gangyi,

>  I am using master branch and newest code for testing.

Cool.

>  For the purpose for learning the structure of gnocchi, I changed the
>  default UUID type of mysql from binary to char, so I can easily link
>  the resource-id(I mean in database), metric id and directory name of
>  storing measures.

Bah, don't do that – and rather use PostgreSQL, it's the recommended
backend. :)

>  When I did that, I found all the metrics where their resource id is
>  combined(here, I mean in Ceilometer, such as instance-xxx-tap)
>  have no measures stored.


>  Log in Ceilometer collector records this:
>  "
>  2015-09-11 07:55:55.097 10636 ERROR ceilometer.dispatcher.gnocchi [-] 
> Resource 
> instance-0001-4641f59e-994c-4255-b0ec-43a276d1c19c-tap8aadb7ad-d7 
> creation failed with status: 400: 
>  
>   400 Bad Request
>  
>  
>   400 Bad Request
>   The server could not comply with the request since it is either malformed 
> or otherwise incorrect.
> Invalid input: required key not provided @ data['display_name']
>   
> 
>
>  "
>  So I wander whether gnocchi cannot deal with such combined resource-id 
> metrics or whether it is because I change the UUID type or whatever.

Yes, it can, but the problem is more likely in the Ceilometer collector
dispatcher code that is sending the data. From the error you have, it
seems it tries to create an instance but it has no value for
display_name, so it is denied by Gnocchi. If this is from a standard
devstack installation, I'd suggest to open a bug on Ceilometer.

>  And another question is how to query measures for those metrics whose
>  resource id is combined.

They are resource on their own so if you know their id you can just
access the metrics at /v1/resources///metric//measures.

>  For example, I want to query the network traffic of an vm, I know the
>  instance uuid -, I know metric name
>  'network.incoming.byte.rate' but I do not know the exact resouce_id
>  and metric id. What procedure should I do ?

You need to know the ID of the resource and then ask for its metric on
the REST interface. If you don't know the ID of the resource, you can
search for it by instance id.

But I don't think Ceilometer has this metric posted to Gnocchi yet, the
code is a bit young and not finished on the Ceilometer side. If you
check gnocchi_resources.yaml, it's still marked "ignored" for now.

-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal withcombined resource-id ?

[Luo Gangyi]

Hi, Chris
 
> With that change in place you can still use the 'instance-xxx-tap' ID
> in the  part of /v1/metric/resource// URLs and in
> search queries.
  
 But we cannot know the tap name through nova api or neutron api.
 In general,  there exists some conditions that we cannot know the exact 
resource id in advance. And using hash of  resource id also makes fuzzy search 
impossible. What we know are some relationships between resources, like a vm 
has several taps. The resource instance-111 and resource instance-111-tap111 
has inborn connections. 
 So I suggest that we should add some attribute to describe such relation.
  
  --
 Luo Gangyi   luogan...@cmss.chinamobile.com__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer][aodh][gnocchi] Tokyo design session planning

[gord chung]

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 other 
monitoring/metering/alarming related project.


official proposals can be submitted here: 
https://docs.google.com/spreadsheets/d/1ea_P2k1kNy_SILEnC-5Zl61IFhqEOrlZ5L8VY4-xNB0/edit?usp=sharing


we've also created an etherpad for those wishing to brainstorm ideas 
before adding formal proposal: 
https://etherpad.openstack.org/p/tokyo-ceilometer-design-summit


we have tentatively set submission deadline for October 5, 2015, which 
will be followed by a public vote.


cheers,

--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Meters

[Abhishek Talwar]

Hi Folks,I have installed a kilo devstack setup install and I am trying to get the memory and disk usage for my VM's. But on checking the "ceilometer meter-list" I can't find memory.usage or disk.usage meters.I am searched a lot for this and still couldn't find a solution. So how to enable these meters to our meter-list. I want all these meters in the ceilometer meter-list so that I can use them to monitor my instances. Currently the output of ceilometer meter-list is as follows:+--++--+--+--+| Name                     | Type       | Resource ID                                  | User ID                          | Project ID                       |+--++--+--+--+| cpu                      | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || cpu_util                 | gauge      | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || disk.read.bytes          | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || disk.read.requests       | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || disk.write.bytes         | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || disk.write.requests      | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || image                    | gauge      | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image                    | gauge      | acd6beef-13e6-4d64-a83d-9e96beac26ef         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image                    | gauge      | ecefcd31-ae47-4079-bd19-efe07f4c33d3         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image.download           | delta      | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image.serve              | delta      | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image.size               | gauge      | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image.size               | gauge      | acd6beef-13e6-4d64-a83d-9e96beac26ef         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image.size               | gauge      | ecefcd31-ae47-4079-bd19-efe07f4c33d3         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image.update             | delta      | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || image.upload             | delta      | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de         |                                  | 22f22fb60bf8496cb60e8498d93d56e8 || instance                 | gauge      | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || instance:m1.small        | gauge      | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77         | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || network.incoming.bytes   | cumulative | nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || network.incoming.packets | cumulative | nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || network.outgoing.bytes   | cumulative | nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 || network.outgoing.packets | cumulative | nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |+--++--+--+--+Thanks and RegardsAbhishek Talwar
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. 

Re: [openstack-dev] [Ceilometer][Aodh] event-alarm fire policy

[liusheng]

Just a personal thought, can we add an ACK to alarm notifier? when an 
event-alarm fired, the alarm state transformed to "alarm", if 
'alarm_action' has been set, the 'alarm_action' will be triggered and 
notify. for event-alarm, a timout can be set to wait the ACK from alarm 
notifier, if the ACK recieved, reset the alarm state to OK, if timeout 
occured, set the alarm state to 'UNKNOWN'. If 'alarm_action' has not 
been set, we just need to recored the alarm state transition history.


在 2015/9/8 7:26, Zhai, Edwin 写道:

All,
Currently, event-alarm is one-shot style: don't fire again for same 
event.  But threshold-alarm is limited periodic style:

1. only get 1 fire for continuous valid datapoints.
2. Would get a new fire if insufficient data followed by valid ones, 
as we reset alarm state upon insufficient data.


So maybe event-alarm should be periodic also. But I'm not sure when to 
reset the alarm state to 'UNKNOWN': after each fire, or when receive 
different event.


Fire a bug @
https://bugs.launchpad.net/aodh/+bug/1493171

Best Rgds,
Edwin

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Aodh] event-alarm fire policy

[Zhai, Edwin]

Liusheng,
Thanks for your idea. I think it guarantees alarm action got called. But I just 
want it fired upon each matching event. E.g. for each instance crash event.


Have talked with MIBU, repeat-actions can be used for this purpose.

Best,
Edwin

On Tue, 8 Sep 2015, liusheng wrote:

Just a personal thought, can we add an ACK to alarm notifier? when an 
event-alarm fired, the alarm state transformed to "alarm", if 
'alarm_action' has been set, the 'alarm_action' will be triggered and 
notify. for event-alarm, a timout can be set to wait the ACK from alarm 
notifier, if the ACK recieved, reset the alarm state to OK, if timeout 
occured, set the alarm state to 'UNKNOWN'. If 'alarm_action' has not 
been set, we just need to recored the alarm state transition history.


在 2015/9/8 7:26, Zhai, Edwin 写道:

All,
Currently, event-alarm is one-shot style: don't fire again for same 
event.  But threshold-alarm is limited periodic style:

1. only get 1 fire for continuous valid datapoints.
2. Would get a new fire if insufficient data followed by valid ones, 
as we reset alarm state upon insufficient data.


So maybe event-alarm should be periodic also. But I'm not sure when to 
reset the alarm state to 'UNKNOWN': after each fire, or when receive 
different event.


Fire a bug @
https://bugs.launchpad.net/aodh/+bug/1493171

Best Rgds,
Edwin

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Best Rgds,
Edwin__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Meters

[gord chung]

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 Talwar wrote:

Hi Folks,


I have installed a *kilo devstack setup* install and I am trying to 
get the *memory and disk usage* for my VM's. But on checking the 
*"ceilometer meter-list"* I can't find memory.usage or disk.usage meters.


I am searched a lot for this and still couldn't find a solution. So 
how to enable these meters to our meter-list.


I want all these meters in the ceilometer meter-list so that I can use 
them to monitor my instances.


|Currently the output of *ceilometer meter-list* is as follows:

|
|+--++--+--+--+
|Name|Type|Resource ID |User ID |Project ID |
+--++--+--+--+
| cpu | cumulative 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| cpu_util | gauge 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| disk.read.bytes | cumulative 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| disk.read.requests | cumulative 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| disk.write.bytes | cumulative 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| disk.write.requests | cumulative 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| image | gauge 
|55a0a2c2-8cfb-4882-ad05-01d7c821b1de||22f22fb60bf8496cb60e8498d93d56e8|
| image | gauge 
| acd6beef-13e6-4d64-a83d-9e96beac26ef||22f22fb60bf8496cb60e8498d93d56e8|
| image | gauge | ecefcd31-ae47-4079-bd19-efe07f4c33d3 
||22f22fb60bf8496cb60e8498d93d56e8|
| image.download | delta 
|55a0a2c2-8cfb-4882-ad05-01d7c821b1de||22f22fb60bf8496cb60e8498d93d56e8|
| image.serve | delta 
|55a0a2c2-8cfb-4882-ad05-01d7c821b1de||22f22fb60bf8496cb60e8498d93d56e8|
| image.size | gauge 
|55a0a2c2-8cfb-4882-ad05-01d7c821b1de||22f22fb60bf8496cb60e8498d93d56e8|
| image.size | gauge 
| acd6beef-13e6-4d64-a83d-9e96beac26ef||22f22fb60bf8496cb60e8498d93d56e8|
| image.size | gauge | ecefcd31-ae47-4079-bd19-efe07f4c33d3 
||22f22fb60bf8496cb60e8498d93d56e8|
| image.update | delta 
|55a0a2c2-8cfb-4882-ad05-01d7c821b1de||22f22fb60bf8496cb60e8498d93d56e8|
| image.upload | delta 
|55a0a2c2-8cfb-4882-ad05-01d7c821b1de||22f22fb60bf8496cb60e8498d93d56e8|
| instance | gauge 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| instance:m1.small | gauge 
|5314c72b-a2b4-4b2b-bcb1-4057c3d96f77|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| network.incoming.bytes | cumulative 
| nova-instance-instance-0022-fa163e3bd74e 
|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| network.incoming.packets | cumulative 
| nova-instance-instance-0022-fa163e3bd74e 
|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| network.outgoing.bytes | cumulative 
| nova-instance-instance-0022-fa163e3bd74e 
|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|
| network.outgoing.packets | cumulative 
| nova-instance-instance-0022-fa163e3bd74e 
|92876a1aad3c477398137b702a8467d3|22f22fb60bf8496cb60e8498d93d56e8|

+--++--+--+--+

Thanks and Regards
Abhishek Talwar
|

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Ceilometer] Meters

[Srikanth Vavilapalli]

Hi

The vcpus, memory and disk usage related nova measurements are of 
"notification" type. So Plz ensure you have the following configuration 
settings in your nova.conf file on your compute node and restart your 
nova-compute service if you made any changes to that file.

instance_usage_audit=True
instance_usage_audit_period=hour
notify_on_state_change=vm_and_task_state
notification_driver = messagingv2
notification_topics = notifications
notify_on_any_change = True

Thanks
Srikanth



From: Abhishek Talwar [mailto:abhishek.tal...@tcs.com]
Sent: Monday, September 07, 2015 11:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Ceilometer] Meters

Hi Folks,


I have installed a kilo devstack setup install and I am trying to get the 
memory and disk usage for my VM's. But on checking the "ceilometer meter-list" 
I can't find memory.usage or disk.usage meters.

I am searched a lot for this and still couldn't find a solution. So how to 
enable these meters to our meter-list.

I want all these meters in the ceilometer meter-list so that I can use them to 
monitor my instances.
Currently the output of ceilometer meter-list is as follows:
+--++--+--+--+
| Name | Type   | Resource ID   
   | User ID  | Project ID   |
+--++--+--+--+
| cpu  | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| cpu_util | gauge  | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| disk.read.bytes  | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| disk.read.requests   | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| disk.write.bytes | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| disk.write.requests  | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| image| gauge  | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image| gauge  | acd6beef-13e6-4d64-a83d-9e96beac26ef  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image| gauge  | ecefcd31-ae47-4079-bd19-efe07f4c33d3  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image.download   | delta  | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image.serve  | delta  | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image.size   | gauge  | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image.size   | gauge  | acd6beef-13e6-4d64-a83d-9e96beac26ef  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image.size   | gauge  | ecefcd31-ae47-4079-bd19-efe07f4c33d3  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image.update | delta  | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| image.upload | delta  | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de  
   |  | 22f22fb60bf8496cb60e8498d93d56e8 |
| instance | gauge  | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| instance:m1.small| gauge  | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77  
   | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 |
| network.incoming.bytes   | cumulative | 
nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 
| 22f22fb60bf8496cb60e8498d93d56e8 |
| network.incoming.packets | cumulative | 
nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 
| 22f22fb60bf8496cb60e8498d93d56e8 |
| network.outgoing.bytes   | cumulative | 
nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c

[openstack-dev] [Ceilometer][Aodh] event-alarm fire policy

[Zhai, Edwin]

All,
Currently, event-alarm is one-shot style: don't fire again for same event.  But 
threshold-alarm is limited periodic style:

1. only get 1 fire for continuous valid datapoints.
2. Would get a new fire if insufficient data followed by valid ones, as we reset 
alarm state upon insufficient data.


So maybe event-alarm should be periodic also. But I'm not sure when to reset the 
alarm state to 'UNKNOWN': after each fire, or when receive different event.


Fire a bug @
https://bugs.launchpad.net/aodh/+bug/1493171

Best Rgds,
Edwin

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] proposal to add Pradeep Kilambi to Ceilometer core

[Pradeep Kilambi]

On Thu, Sep 3, 2015 at 12:42 PM, gord chung  wrote:

>
>
> 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://review.openstack.org/#/c/218822/ . if for whatever reason you
>> cannot vote there, please respond to this.
>>
>> reviews:
>>
>> https://review.openstack.org/#/q/reviewer:%22Pradeep+Kilambi%22++project:openstack/ceilometer,n,z
>>
>> patches:
>>
>> https://review.openstack.org/#/q/owner:%22Pradeep+Kilambi%22+status:merged+project:openstack/ceilometer,n,z
>>
>> cheers,
>>
>> i'm please to welcome Pradeep to the Ceilometer core team. keep on
> keeping on.



Thanks! Appreciate the opportunity!



-- 
--
Pradeep Kilambi; irc: pradk
OpenStack Engineering
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] proposal to add Liusheng to Ceilometer core

[gord chung]

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://review.openstack.org/#/c/218819/ . if for whatever reason you 
cannot vote there, please respond to this.


reviews:
https://review.openstack.org/#/q/reviewer:liusheng+project:openstack/ceilometer,n,z 



patches:
https://review.openstack.org/#/q/owner:liusheng+status:merged+project:openstack/ceilometer,n,z 



cheers,



it's my pleasure to welcome Liusheng to the Ceilometer core team. thanks 
for the great work you've done and will do.


cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] proposal to add Pradeep Kilambi to Ceilometer core

[gord chung]

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://review.openstack.org/#/c/218822/ . if for whatever reason you 
cannot vote there, please respond to this.


reviews:
https://review.openstack.org/#/q/reviewer:%22Pradeep+Kilambi%22++project:openstack/ceilometer,n,z 



patches:
https://review.openstack.org/#/q/owner:%22Pradeep+Kilambi%22+status:merged+project:openstack/ceilometer,n,z 



cheers,

i'm please to welcome Pradeep to the Ceilometer core team. keep on 
keeping on.


cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] proposal to add Liusheng to Ceilometer core

[gord chung]

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 you 
cannot vote there, please respond to this.


reviews:
https://review.openstack.org/#/q/reviewer:liusheng+project:openstack/ceilometer,n,z

patches:
https://review.openstack.org/#/q/owner:liusheng+status:merged+project:openstack/ceilometer,n,z

cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] proposal to add Pradeep Kilambi to Ceilometer core

[gord chung]

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 for whatever reason you 
cannot vote there, please respond to this.


reviews:
https://review.openstack.org/#/q/reviewer:%22Pradeep+Kilambi%22++project:openstack/ceilometer,n,z

patches:
https://review.openstack.org/#/q/owner:%22Pradeep+Kilambi%22+status:merged+project:openstack/ceilometer,n,z

cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [rally] [sahara] [heat] [congress] [tripleo] ceilometer in gate jobs

[Tim Hinrichs]

I pushed a patch for Congress dependent on your patch.

https://review.openstack.org/#/c/217765/

Tim


On Thu, Aug 27, 2015 at 8:05 AM Sergey Lukjanov slukja...@mirantis.com
wrote:

 Hi,

 I think filing the cross-project bug is ok. I've already uploaded patch
 for sahara jobs - https://review.openstack.org/217751

 Thanks.

 On Wed, Aug 26, 2015 at 6:46 PM, Chris Dent chd...@redhat.com wrote:


 [If any of this is wrong I hope someone from infra or qa will
 correct me. Thanks. This feels a bit cumbersome so perhaps there is
 a way to do it in a more automagic fashion[1].]

 In the near future ceilometer will be removing itself from the core
 of devstack and using a plugin instead. This is to allow more
 independent control and flexibility.

 These are the related reviews:

 * remove from devstack: https://review.openstack.org/196383
 * updated jenkins jobs: https://review.openstack.org/196446

 If a project is using ceilometer in its gate jobs then before the
 above can merge adjustments need to be made to make sure that the
 ceilometer plugin is enabled. The usual change for this would be a
 form of:

   DEVSTACK_LOCAL_CONFIG+=$'\n'enable_plugin ceilometer git://
 git.openstack.org/openstack/ceilometer

 I'm not entirely clear on what we will need to do coordinate this,
 but it is clear some coordination will need to be done such that
 ceilometer remains in devstack until everything that is using
 ceilometer in devstack is ready to use the plugin.

 A grep through the jenkins jobs suggests that the projects in
 $SUBJECT (rally, sahara, heat, congress, tripleo) will need some
 changes.

 How shall we proceed with this?

 One option is for project team members[2] to make a stack of dependent
 patches that are dependent on 196446 above (which itself is dependent
 on 196383) so that it all happens in one fell swoop.

 What are the other options?

 Thanks for your input.

 [1] That is, is it worth considering adding functionality to
 devstack's sense of enabled such that if a service is enabled
 devstack knows how to look for a plugin if it doesn't find local
 support. With the destruction of the stackforge namespace we can
 perhaps guess the git URL for plugins?

 [2] Or me if that's better.

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [rally] [sahara] [heat] [congress] [tripleo] ceilometer in gate jobs

[Sergey Lukjanov]

Hi,

I think filing the cross-project bug is ok. I've already uploaded patch for
sahara jobs - https://review.openstack.org/217751

Thanks.

On Wed, Aug 26, 2015 at 6:46 PM, Chris Dent chd...@redhat.com wrote:


 [If any of this is wrong I hope someone from infra or qa will
 correct me. Thanks. This feels a bit cumbersome so perhaps there is
 a way to do it in a more automagic fashion[1].]

 In the near future ceilometer will be removing itself from the core
 of devstack and using a plugin instead. This is to allow more
 independent control and flexibility.

 These are the related reviews:

 * remove from devstack: https://review.openstack.org/196383
 * updated jenkins jobs: https://review.openstack.org/196446

 If a project is using ceilometer in its gate jobs then before the
 above can merge adjustments need to be made to make sure that the
 ceilometer plugin is enabled. The usual change for this would be a
 form of:

   DEVSTACK_LOCAL_CONFIG+=$'\n'enable_plugin ceilometer git://
 git.openstack.org/openstack/ceilometer

 I'm not entirely clear on what we will need to do coordinate this,
 but it is clear some coordination will need to be done such that
 ceilometer remains in devstack until everything that is using
 ceilometer in devstack is ready to use the plugin.

 A grep through the jenkins jobs suggests that the projects in
 $SUBJECT (rally, sahara, heat, congress, tripleo) will need some
 changes.

 How shall we proceed with this?

 One option is for project team members[2] to make a stack of dependent
 patches that are dependent on 196446 above (which itself is dependent
 on 196383) so that it all happens in one fell swoop.

 What are the other options?

 Thanks for your input.

 [1] That is, is it worth considering adding functionality to
 devstack's sense of enabled such that if a service is enabled
 devstack knows how to look for a plugin if it doesn't find local
 support. With the destruction of the stackforge namespace we can
 perhaps guess the git URL for plugins?

 [2] Or me if that's better.

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] [rally] [sahara] [heat] [congress] [tripleo] ceilometer in gate jobs

[Chris Dent]

[If any of this is wrong I hope someone from infra or qa will
correct me. Thanks. This feels a bit cumbersome so perhaps there is
a way to do it in a more automagic fashion[1].]

In the near future ceilometer will be removing itself from the core
of devstack and using a plugin instead. This is to allow more
independent control and flexibility.

These are the related reviews:

* remove from devstack: https://review.openstack.org/196383
* updated jenkins jobs: https://review.openstack.org/196446

If a project is using ceilometer in its gate jobs then before the
above can merge adjustments need to be made to make sure that the
ceilometer plugin is enabled. The usual change for this would be a
form of:

  DEVSTACK_LOCAL_CONFIG+=$'\n'enable_plugin ceilometer 
git://git.openstack.org/openstack/ceilometer

I'm not entirely clear on what we will need to do coordinate this,
but it is clear some coordination will need to be done such that
ceilometer remains in devstack until everything that is using
ceilometer in devstack is ready to use the plugin.

A grep through the jenkins jobs suggests that the projects in
$SUBJECT (rally, sahara, heat, congress, tripleo) will need some
changes.

How shall we proceed with this?

One option is for project team members[2] to make a stack of dependent
patches that are dependent on 196446 above (which itself is dependent
on 196383) so that it all happens in one fell swoop.

What are the other options?

Thanks for your input.

[1] That is, is it worth considering adding functionality to
devstack's sense of enabled such that if a service is enabled
devstack knows how to look for a plugin if it doesn't find local
support. With the destruction of the stackforge namespace we can
perhaps guess the git URL for plugins?

[2] Or me if that's better.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] now using a grenade plugin

[Chris Dent]

Since it provides an opportunity to do some interesting things I
thought I should announce that ceilometer has left the core of
grenade and is now running its own 'gate-grenade-dsvm-ceilometer'
job that uses a grenade plugin hosted in the ceilometer repo.

At the moment the plugin does the bare minimum of checks to confirm that
the upgrade was successful (in devstack/upgrade/upgrade.sh).

Now that the plugin is in repo we have a lot of flexibility to do
whatever we want and we should.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] jenkis job failures

[Chris Dent]

On Wed, 26 Aug 2015, Ryota Mibu wrote:


Quick note to ceilometer folks.

Many check and gate jobs for ceilometer are failed due to WSME related
issue that is already addressed by [1], so please make sure your patch
set are rebased on the current master before execute 'recheck'.


Thanks for posting about this.

I've gone through this morning and rebased some of the pending
patches that just needed a rebase to get moving.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] now using a grenade plugin

[Sean Dague]

On 08/26/2015 05:14 AM, Chris Dent wrote:
 
 Since it provides an opportunity to do some interesting things I
 thought I should announce that ceilometer has left the core of
 grenade and is now running its own 'gate-grenade-dsvm-ceilometer'
 job that uses a grenade plugin hosted in the ceilometer repo.
 
 At the moment the plugin does the bare minimum of checks to confirm that
 the upgrade was successful (in devstack/upgrade/upgrade.sh).
 
 Now that the plugin is in repo we have a lot of flexibility to do
 whatever we want and we should.
 

Thanks for all the hard work to make this happen.

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] jenkis job failures

[Ryota Mibu]

Hi,


Quick note to ceilometer folks.

Many check and gate jobs for ceilometer are failed due to WSME related issue 
that is already addressed by [1], so please make sure your patch set are 
rebased on the current master before execute 'recheck'.

[1] https://review.openstack.org/#/c/208467/


Thanks,
Ryota

---
Ryota Mibu r-m...@cq.jp.nec.com
NEC Corporation


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[Igor Degtiarov]

Hi,

As far as I understand we have a base agreement that both specs are
appropriate and either of that two features are shifted to Mitaka cycle.

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?
And the second one: are we going to create special rep for AODH specs or
ceilometer-specs is ok for all new projects?

Thank you in advance,
Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Fri, Aug 7, 2015 at 10:59 AM, Ryota Mibu r-m...@cq.jp.nec.com wrote:

 Hi,


 Sorry for my late response and my absent in weekly meetings...

 I'm not sure whether I captured your idea correctly, but I prefer the
 second approach now.

 I agreed the point Igor and liusheng mentioned that the second approach
 enables end users to have configurable expire-time.

 In another point of view, the first approach may affect pipeline
 performance since it have to keep event sequence state or have to access DB
 for state querying when each event received. This is just my concern, but I
 think event pipeline should be simplest and limited to have only common
 features between event data storage, event alarming and other receiver like
 audit system.


 Thanks,
 Ryota

  -Original Message-
  From: liusheng [mailto:liusheng1...@126.com]
  Sent: Wednesday, August 05, 2015 1:12 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms
 
  Hi,
 
  Maybe the event transformer is needed in some use cases to generate new
 events or do transformations like the samples
  handling.  but for this timeout event alarming requirement,  the
 'timeout' of alarms will be various, it not a good idea
  of changing event_pipeline.yaml to generate new events based on events
 timeout when we need an event-timeout alarm. and
  also, the access of event pipeline definitions to users is inadvisable.
 I personally think it'd better to implement the
  second option and based on Ryota's proposal.
 
  Best Regards
  Liusheng
 
 
  在 2015/8/5 3:36, gord chung 写道:
 
 
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 able to get this into
 Liberty if we went the pipeline route.
 
[1]
 http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
 
 
On 04/08/2015 10:00 AM, Igor Degtiarov wrote:
 
 
Hi folks,
 
 
On our meatup we agreed to add timeout event alarms
 [1](Event-Base Alarming part).
In ToDo task Сhoose the optimal way for timeout alerting
 implementation
 
Now we have two proposition for implementation:
 
 - first is to add timeout param in event pipeline
 (transformer part) [2]
   -- weakness of this approach is that we cannot allow
 user change config files, so only administrator
  will be able to set rules for timeout events alarms, and that is not
 what we are expecting from alarms.
 
 - second is additional optional parameters in event
 alarms description like sequence of required events
  and timeout threshold. Event alarm evaluator looks thru getting events
 and evaluates alarm if even one event from required
  sequence isn't received in set timeout.[3]
 
 
It seems that second approach is better it doesn't have
 restrictions for end user.
 
Hope for your help in choosing optimal way for
 implementation.
(In specs review there is silence now)
 
 
[1]
 https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005
 
 
Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com
 
 
 
 
  __
OpenStack Development Mailing List (not for usage
 questions)
Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
--
--
gord
 
 
 
 
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 __
 OpenStack Development Mailing List

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[Igor Degtiarov]

Gordon thanks for quick answer.

I'll add a patch with new dir for mitaka specs and move my specs there.


cheers,

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Mon, Aug 17, 2015 at 7:02 PM, gord chung g...@live.ca wrote:

 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 week's
 meeting, even though we don't have a exact date for feature freeze, unless
 it's a small bug size spec, Liberty specs are closed. feel free to create a
 patch for new M* dir

 And the second one: are we going to create special rep for AODH specs or
 ceilometer-specs is ok for all new projects?


 we'll track aodh specs under ceilometer now -- i don't want to increase
 the number of repos we need to monitor unless we notice Aodh specs are too
 much to handle.

 cheers,


 --
 gord


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[gord chung]

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 week's 
meeting, even though we don't have a exact date for feature freeze, 
unless it's a small bug size spec, Liberty specs are closed. feel free 
to create a patch for new M* dir


And the second one: are we going to create special rep for AODH specs 
or ceilometer-specs is ok for all new projects?


we'll track aodh specs under ceilometer now -- i don't want to increase 
the number of repos we need to monitor unless we notice Aodh specs are 
too much to handle.


cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [aodh] upgrade path

[gord chung]

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 probably be resolved by knowing the answer to
this question:

If someone installs aodh on a machine that already has ceilometer on it
and turns off ceilometer-alarm-notifier and ceilometer-alarm-evaluator
(in favor of aodh-notifier and aodh-evaluator) will they be able to run
those aodh services against their existing ceilometer.conf files[2]?

What if they were, in ceilometer, using specific config for their
alarming database (alarm_connection). Can aodh see and use this
config option?

Or will they need to copy and modify the existing conf files to allow
them to carry on using their existing database config?

I know that I can go try some of this in a devstack, but that's not
really the point of the question. The point is: What are we expecting
existing deployments to do?

I had assumed that the reason for keeping alarming in ceilometer for
the liberty release was to allow a deployment to upgrade to Liberty
across the project suites without having to go through modifying
alarming config and managing an alarming migration in the same step.
That migration ought to be pretty minor (tweak a config here and
there) but unless the answer to my first question is yes it has some
significance.


following up, after speaking with Chris, a critical question was not 
just what happens to those who upgrade but what happens to those who 
choose NOT to upgrade to Aodh. to clarify, it is Ceilometer's intent to 
have Aodh as the source of alarming functionality going forward -- no 
new features have been added or will be added to the existing alarming 
code in Ceilometer. also, any new feature must be added to Aodh.


with that said, for those who choose not to upgrade and are content with 
existing alarming code, the code will exist as is for Liberty. after 
speaking with the Nova team, there has been a deprecation period between 
Cinder/Glance split before it was fully removed from packaging/code. 
Ceilometer will follow the same but will target a more aggressive 
deprecation period and the code will be removed in M* cycle.


the code removal is dependent on Aodh being gated on, released and 
packaged. it is also dependent on any upgrade requirements being documented.


the goals for a short deprecation is:
- to avoid a slow complicated divergence in code that will lead to 
difficult maintenance

- to allow time for packagers to package the new Aodh service
- to give operators, tracking the latest and greatest, the option of 
whether to upgrade to Aodh or not.


i hope that clarifies our intentions. this is our first split so if 
there are any noticeable gaps in logic, please feel free to chime in.


cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[Ryota Mibu]

Hi,


Sorry for my late response and my absent in weekly meetings...

I'm not sure whether I captured your idea correctly, but I prefer the second 
approach now.

I agreed the point Igor and liusheng mentioned that the second approach enables 
end users to have configurable expire-time.

In another point of view, the first approach may affect pipeline performance 
since it have to keep event sequence state or have to access DB for state 
querying when each event received. This is just my concern, but I think event 
pipeline should be simplest and limited to have only common features between 
event data storage, event alarming and other receiver like audit system.


Thanks,
Ryota

 -Original Message-
 From: liusheng [mailto:liusheng1...@126.com]
 Sent: Wednesday, August 05, 2015 1:12 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms
 
 Hi,
 
 Maybe the event transformer is needed in some use cases to generate new 
 events or do transformations like the samples
 handling.  but for this timeout event alarming requirement,  the 'timeout' of 
 alarms will be various, it not a good idea
 of changing event_pipeline.yaml to generate new events based on events 
 timeout when we need an event-timeout alarm. and
 also, the access of event pipeline definitions to users is inadvisable. I 
 personally think it'd better to implement the
 second option and based on Ryota's proposal.
 
 Best Regards
 Liusheng
 
 
 在 2015/8/5 3:36, gord chung 写道:
 
 
   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 able to get this into 
 Liberty if we went the pipeline route.
 
   [1] 
 http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
 
 
   On 04/08/2015 10:00 AM, Igor Degtiarov wrote:
 
 
   Hi folks,
 
 
   On our meatup we agreed to add timeout event alarms 
 [1](Event-Base Alarming part).
   In ToDo task Сhoose the optimal way for timeout alerting 
 implementation
 
   Now we have two proposition for implementation:
 
- first is to add timeout param in event pipeline (transformer 
 part) [2]
  -- weakness of this approach is that we cannot allow user 
 change config files, so only administrator
 will be able to set rules for timeout events alarms, and that is not what we 
 are expecting from alarms.
 
- second is additional optional parameters in event alarms 
 description like sequence of required events
 and timeout threshold. Event alarm evaluator looks thru getting events and 
 evaluates alarm if even one event from required
 sequence isn't received in set timeout.[3]
 
 
   It seems that second approach is better it doesn't have 
 restrictions for end user.
 
   Hope for your help in choosing optimal way for implementation.
   (In specs review there is silence now)
 
 
   [1] 
 https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
   [2] https://review.openstack.org/#/c/162167
   [3] https://review.openstack.org/#/c/199005
 
 
   Igor Degtiarov
   Software Engineer
   Mirantis Inc.
   www.mirantis.com
 
 
 
   
 __
   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
   --
   --
   gord
 
 
 
   
 __
   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [aodh] upgrade path

[Julien Danjou]

On Fri, Aug 07 2015, Chris Dent wrote:

 If someone installs aodh on a machine that already has ceilometer on it
 and turns off ceilometer-alarm-notifier and ceilometer-alarm-evaluator
 (in favor of aodh-notifier and aodh-evaluator) will they be able to run
 those aodh services against their existing ceilometer.conf files[2]?

Yes, because none of the option has been changed, and those who have
been changed have been deprecated, e.g. deprecated_group=foobar.

 What if they were, in ceilometer, using specific config for their
 alarming database (alarm_connection). Can aodh see and use this
 config option?

That's the only option where maybe I cleaned-up a little bit too much as
I think I remove the alarm_connection from Aodh. I'll cook a patch to
fix that.

 Or will they need to copy and modify the existing conf files to allow
 them to carry on using their existing database config?

Well ultimately as soon as they start using aodh, they could copy
ceilometer.conf, remove what's ceilometer only related and voilà. That
can be achieved by comparing with the default aodh.conf I guess.

We could test that upgrade path using Grenade maybe?

I hope I made things clearer!

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] [aodh] upgrade path

[Chris Dent]

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 probably be resolved by knowing the answer to
this question:

If someone installs aodh on a machine that already has ceilometer on it
and turns off ceilometer-alarm-notifier and ceilometer-alarm-evaluator
(in favor of aodh-notifier and aodh-evaluator) will they be able to run
those aodh services against their existing ceilometer.conf files[2]?

What if they were, in ceilometer, using specific config for their
alarming database (alarm_connection). Can aodh see and use this
config option?

Or will they need to copy and modify the existing conf files to allow
them to carry on using their existing database config?

I know that I can go try some of this in a devstack, but that's not
really the point of the question. The point is: What are we expecting
existing deployments to do?

I had assumed that the reason for keeping alarming in ceilometer for
the liberty release was to allow a deployment to upgrade to Liberty
across the project suites without having to go through modifying
alarming config and managing an alarming migration in the same step.
That migration ought to be pretty minor (tweak a config here and
there) but unless the answer to my first question is yes it has some
significance.

[1] 
http://eavesdrop.openstack.org/meetings/ceilometer/2015/ceilometer.2015-08-06-15.01.log.html#l-110

[2] directly as in aodh-notifier --config-file /etc/ceilometer/ceilometer.conf

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [aodh] upgrade path

[Chris Dent]

On Fri, 7 Aug 2015, Julien Danjou wrote:


On Fri, Aug 07 2015, Chris Dent wrote:


If someone installs aodh on a machine that already has ceilometer on it
and turns off ceilometer-alarm-notifier and ceilometer-alarm-evaluator
(in favor of aodh-notifier and aodh-evaluator) will they be able to run
those aodh services against their existing ceilometer.conf files[2]?


Yes, because none of the option has been changed, and those who have
been changed have been deprecated, e.g. deprecated_group=foobar.


Excellent, glad to hear it.


What if they were, in ceilometer, using specific config for their
alarming database (alarm_connection). Can aodh see and use this
config option?


That's the only option where maybe I cleaned-up a little bit too much as
I think I remove the alarm_connection from Aodh. I'll cook a patch to
fix that.


Glad we flushed that out[1].


We could test that upgrade path using Grenade maybe?


Yes[2]. We'd have to instrument how wanted to manage both the
installation of aodh and the config, but one of the advantages of
having grenade as a plugin would be that we can do what we need to
do (to some extent).


I hope I made things clearer!


Yes, thanks very much. IRC is dismal enough for reasoned discussion and
resolution but even worse for ensuring decisions have lasting and visible
effect.

[1] https://review.openstack.org/#/c/210286/
[2] Assuming we can get the various pieces to fall into place so
that we have working grenade plugins in all the right places.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] Do we have test coverage goals?

[Chris Dent]

The recent split of the unit and functional tests in ceilometer
shows some interesting test coverage data. With just what are now
called the unit tests coverage is a meek 58%. With both the unit
and functional (what used to be the standard coverage run) the
coverage is a still kind of meek 84%.

Do we have, or do we want to have, a particular coverage target for
the code. Or if not all the code then at least some sections of it?

Do we want that metric of coverage to be against just the unit tests
or unit and functional?

Note that these numbers are thrown off quite a bit by various
artifacts like database migration files so are not a super accurate
overview of true test coverage, just a (potentially) useful indicator.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [aodh] upgrade path

[gord chung]

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 probably be resolved by knowing the answer to
this question:

If someone installs aodh on a machine that already has ceilometer on it
and turns off ceilometer-alarm-notifier and ceilometer-alarm-evaluator
(in favor of aodh-notifier and aodh-evaluator) will they be able to run
those aodh services against their existing ceilometer.conf files[2]?


it also depends on how you're consuming ceilometer. if you're installing 
ceilometer services via packages, there will never be aodh or 
ceilometer-alarm... just one alarming service. once we get aodh 
released/packaged, from a package pov, the current, deprecated code will 
be inaccessible.


http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-08-06.log.html#t2015-08-06T15:46:17 



--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[Igor Degtiarov]

Hi folks,

On our meatup we agreed to add timeout event alarms [1](Event-Base Alarming
part).
In ToDo task Сhoose the optimal way for timeout alerting implementation
Now we have two proposition for implementation:
 - first is to add timeout param in event pipeline (transformer part)
[2]
   -- weakness of this approach is that we cannot allow user change config
files, so only administrator will be able to set rules for timeout events
alarms, and that is not what we are expecting from alarms.
 - second is additional optional parameters in event alarms description
like sequence of required events and timeout threshold. Event alarm
evaluator looks thru getting events and evaluates alarm if even one event
from required sequence isn't received in set timeout.[3]

It seems that second approach is better it doesn't have restrictions for
end user.
Hope for your help in choosing optimal way for implementation.
(In specs review there is silence now)

[1]
https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[liusheng]

Hi,

Maybe the event transformer is needed in some use cases to generate new 
events or do transformations like the samples handling.  but for this 
timeout event alarming requirement,  the 'timeout' of alarms will be 
various, it not a good idea of changing event_pipeline.yaml to generate 
new events based on events timeout when we need an event-timeout alarm. 
and also, the access of event pipeline definitions to users is 
inadvisable. I personally think it'd better to implement the second 
option and based on Ryota's proposal.


Best Regards
Liusheng

在 2015/8/5 3:36, gord chung 写道:

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 able to get this into Liberty if we went the pipeline route.


[1] 
http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html


On 04/08/2015 10:00 AM, Igor Degtiarov wrote:

Hi folks,

On our meatup we agreed to add timeout event alarms [1](Event-Base 
Alarming part).

In ToDo task Сhoose the optimal way for timeout alerting implementation
Now we have two proposition for implementation:
 - first is to add timeout param in event pipeline (transformer part) 
[2]
   -- weakness of this approach is that we cannot allow user change 
config files, so only administrator will be able to set rules for 
timeout events alarms, and that is not what we are expecting from alarms.
 - second is additional optional parameters in event alarms 
description like sequence of required events and timeout threshold. 
Event alarm evaluator looks thru getting events and evaluates alarm 
if even one event from required sequence isn't received in set 
timeout.[3]


It seems that second approach is better it doesn't have restrictions 
for end user.

Hope for your help in choosing optimal way for implementation.
(In specs review there is silence now)

[1] 
https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle

[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com http://www.mirantis.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[gord chung]

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 able to get this into Liberty if we went the pipeline route.


[1] 
http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html


On 04/08/2015 10:00 AM, Igor Degtiarov wrote:

Hi folks,

On our meatup we agreed to add timeout event alarms [1](Event-Base 
Alarming part).

In ToDo task Сhoose the optimal way for timeout alerting implementation
Now we have two proposition for implementation:
 - first is to add timeout param in event pipeline (transformer part) [2]
   -- weakness of this approach is that we cannot allow user change 
config files, so only administrator will be able to set rules for 
timeout events alarms, and that is not what we are expecting from alarms.
 - second is additional optional parameters in event alarms 
description like sequence of required events and timeout threshold. 
Event alarm evaluator looks thru getting events and evaluates alarm if 
even one event from required sequence isn't received in set timeout.[3]


It seems that second approach is better it doesn't have restrictions 
for end user.

Hope for your help in choosing optimal way for implementation.
(In specs review there is silence now)

[1] 
https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle

[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com http://www.mirantis.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer

[Srikanth Vavilapalli]

Thanks gord. I will enable store_events and see if neutron related 
meters/state events are appearing under ceilometer events-list

Thanks
Srikanth

-Original Message-
From: gord chung [mailto:g...@live.ca] 
Sent: Thursday, July 30, 2015 2:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] Unable to get the neutron network 
related meters in ceilometer


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 ceilometer services.. Hope this helps others...

 [notification]
 disable_non_metric_meters = false

to followup, in Ceilometer, we capture data in two different models: 
Meters and Events[1]. Meters are designed for numeric, measurement data such 
as: cpu time, cpu_util, incoming.bytes, etc... Events are a more generic model 
which represent the state of a resource. historically, we never had Events so 
we captured non-measurement data (see Neutron
'meters') as Meters. going forward, consumers should enable store_events (if 
not already) to capture non-measurement data as Events. Events offer better 
granularity and are more query-able.

[1]
http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html

cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer

[gord chung]

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 ceilometer services.. Hope this helps others...

[notification]
disable_non_metric_meters = false


to followup, in Ceilometer, we capture data in two different models: 
Meters and Events[1]. Meters are designed for numeric, measurement data 
such as: cpu time, cpu_util, incoming.bytes, etc... Events are a more 
generic model which represent the state of a resource. historically, we 
never had Events so we captured non-measurement data (see Neutron 
'meters') as Meters. going forward, consumers should enable store_events 
(if not already) to capture non-measurement data as Events. Events offer 
better granularity and are more query-able.


[1] 
http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html


cheers,

--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer

[Srikanth Vavilapalli]

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 ceilometer services.. Hope this helps others... 

[notification]
disable_non_metric_meters = false

Thanks
Srikanth


-Original Message-
From: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com] 
Sent: Wednesday, July 29, 2015 2:25 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ceilometer] Unable to get the neutron network related 
meters in ceilometer

Hi

I have manually installed latest ceilometer service in my devstack (master 
branch) cluster with MongoDB as backend. I have configured all the ceilometer 
services (notification, central, collector, api services on controller node and 
 ceilometer-agent-compute on compute nodes) as per the installation guide. Also 
I have enabled nova, glance, cinder and neutron to send notifications 
to oslo messaging queue by modifying the corresponding .conf file. 

When I run ceilometer meter-list command, I can see only the meters from 
compute, glance and cinder, but not from neutron service. Could any of 
provide me any pointers on how I can troubleshoot this issue? Plz let me know 
if you need any info from my setup..

Thanks
Srikanth

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer

[Srikanth Vavilapalli]

Hi

I have manually installed latest ceilometer service in my devstack (master 
branch) cluster with MongoDB as backend. I have configured all the ceilometer 
services (notification, central, collector, api services on controller node and 
 ceilometer-agent-compute on compute nodes) as per the installation guide. Also 
I have enabled nova, glance, cinder and neutron to send notifications 
to oslo messaging queue by modifying the corresponding .conf file. 

When I run ceilometer meter-list command, I can see only the meters from 
compute, glance and cinder, but not from neutron service. Could any of 
provide me any pointers on how I can troubleshoot this issue? Plz let me know 
if you need any info from my setup..

Thanks
Srikanth

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[Julien Danjou]

On Thu, Jul 16 2015, Angus Salkeld wrote:

Hi Angus,

 I just saw this, and I am concerned this is going to kill Heat's gate (and
 user's templates).

 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?

As Gordon said, don't worry, we'll do everything to not break Heat's
gate, managing transition. We're setting up a plan and I think Mehdi
already has patches doing magic so it's transparent and painless for
everyone.

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[Angus Salkeld]

On Fri, Jul 17, 2015 at 8:52 PM, Julien Danjou jul...@danjou.info wrote:

 On Thu, Jul 16 2015, Angus Salkeld wrote:

 Hi Angus,

  I just saw this, and I am concerned this is going to kill Heat's gate
 (and
  user's templates).
 
  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?

 As Gordon said, don't worry, we'll do everything to not break Heat's
 gate, managing transition. We're setting up a plan and I think Mehdi
 already has patches doing magic so it's transparent and painless for
 everyone.


OK, thanks - phew.

-Angus



 --
 Julien Danjou
 # Free Software hacker
 # http://julien.danjou.info

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[gord chung]

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 functionality to 
persist as is until we have a document process to transition over to 
split Aodh service. We are currently looking at the existing integration 
cases and have them prioritised. Once we have integrations all resolved 
we will announce code removal. It is currently targeted to be removed in 
M* cycle, dependent on current integration work.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[Angus Salkeld]

On Tue, Jun 30, 2015 at 6:09 PM, Julien Danjou jul...@danjou.info wrote:

 On Mon, Jun 29 2015, Ildikó Váncsa wrote:

  I think removing options from the API requires version bump. So if we
 plan to
  do this, that should be introduced in v3 as opposed to v2, which should
 remain
  the same and maintained for two cycles (assuming that we still have this
 policy
  in OpenStack). It this is achievable by removing the old code and
 relying on
  the new repo that would be the best, if not then we need to figure out
 how to
  freeze the old code.

 This is not an API change as we're not modifying anything in the API.
 It's just the endpoint *potentially* split in two. But you can also
 merge them as they are 2 separate entities (/v2/alarms and /v2/*).
 So there's no need for a v3 here.


Hi Julien,

I just saw this, and I am concerned this is going to kill Heat's gate (and
user's templates).

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?

-Angus



 As the consensus goes toward removal, I'll work on a patch for that.

 --
 Julien Danjou
 /* Free Software hacker
http://julien.danjou.info */

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev