Re: [openstack-dev] [aodh] threshold rule alarms deprecation

On Tue, Feb 28 2017, gordon chung wrote: > this is a continuation of the ceilometer-api is deprecated discussion. > with that marked as deprecated as of Ocata, what do we do with threshold > rule alarms as it relies on ceilometer-api? logically, we'd deprecate it > as well. this will require

[openstack-dev] [aodh] threshold rule alarms deprecation

hi, this is a continuation of the ceilometer-api is deprecated discussion. with that marked as deprecated as of Ocata, what do we do with threshold rule alarms as it relies on ceilometer-api? logically, we'd deprecate it as well. this will require heat as well to deprecate it on their end.

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 02/02/2017, 15:43, "gordon chung" wrote: > > On 02/02/17 06:30 AM, Afek, Ifat (Nokia - IL) wrote: > > I understand. So clearly the use case of Vitrage raising alarms in Aodh is > > not relevant at the moment. > > We will have to think if over and see how Panko fits in the

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 02/02/17 06:30 AM, Afek, Ifat (Nokia - IL) wrote: > I understand. So clearly the use case of Vitrage raising alarms in Aodh is > not relevant at the moment. > We will have to think if over and see how Panko fits in the use case. if the use case is that you wanted to store history of Vitrage

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 31/01/2017, 18:43, "gordon chung" wrote: > On 31/01/17 08:34 AM, Afek, Ifat (Nokia - IL) wrote: > > If you query Vitrage (or get a notification from Vitrage) and then you > > query Aodh, then Aodh will not return any additional information. But – if > > you query only Aodh,

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 31/01/17 08:34 AM, Afek, Ifat (Nokia - IL) wrote: > If you query Vitrage (or get a notification from Vitrage) and then you query > Aodh, then Aodh will not return any additional information. But – if you > query only Aodh, you will be aware of the fact that the instances are at > risk.

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 30/01/2017, 19:11, "gordon chung" wrote: > > On 29/01/17 08:52 AM, Afek, Ifat (Nokia - IL) wrote: > > > > Vitrage could be enhanced to become an alarm orchestrator. > > The question is – do you want Vitrage to be one? > > And how would you describe the role of an alarm

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 29/01/17 08:52 AM, Afek, Ifat (Nokia - IL) wrote: > On 26/01/2017, 20:09, "Julien Danjou" wrote: > >> On Thu, Jan 26 2017, gordon chung wrote: >> >>> On 26/01/17 11:41 AM, Julien Danjou wrote: >> >>> and vitrage would be an alarm orchestrator? >> >> Yup, something like

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 26/01/2017, 20:09, "Julien Danjou" wrote: > On Thu, Jan 26 2017, gordon chung wrote: > > > On 26/01/17 11:41 AM, Julien Danjou wrote: > > > and vitrage would be an alarm orchestrator? > > Yup, something like that. It could be the one driving Zabbix and > creating

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Thu, Jan 26 2017, gordon chung wrote: > On 26/01/17 11:41 AM, Julien Danjou wrote: >> So here's another question then: why wouldn't there be a "zabbix" alarm >> type in Aodh that could be created by a user (or another program) and >> that would be triggered by Aodh when Zabbix does something?

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 26/01/17 11:41 AM, Julien Danjou wrote: > So here's another question then: why wouldn't there be a "zabbix" alarm > type in Aodh that could be created by a user (or another program) and > that would be triggered by Aodh when Zabbix does something? > Which is something that is really like the

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Thu, Jan 26 2017, Afek, Ifat (Nokia - IL) wrote: > I’ll try to answer your question from a user perspective. Thanks for your explanation, it helped me a lot to understand how you view things. :) > Suppose a bridge has a bond of two physical ports, and Zabbix detects a signal > loss in one

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 25/01/2017, 17:12, "Julien Danjou" wrote: > On Wed, Jan 25 2017, Afek, Ifat (Nokia - IL) wrote: > > To circle back to the original point, the main question that I asked and > started this thread is: why, why Aodh should store Vitrage alarms? What > are the advantages,

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Wed, Jan 25 2017, Afek, Ifat (Nokia - IL) wrote: > As we see it, alarms can be generated by different sources – Aodh, Vitrage, > Nagios, Zabbix, etc. I think "generated" is the wrong word here. Aodh does not generate any alarms: it allows users to create them. And then it evaluates them and

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 25/01/17 08:39 AM, Afek, Ifat (Nokia - IL) wrote: > As we see it, alarms can be generated by different sources – Aodh, Vitrage, > Nagios, Zabbix, etc. Each source has its own expertise and internal > implementation. Nagios and Zabbix can raise alarms about the physical layer, > Aodh can

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

Hi, Alarm history and a database are definitely important, but they are not the main issue here. As we see it, alarms can be generated by different sources – Aodh, Vitrage, Nagios, Zabbix, etc. Each source has its own expertise and internal implementation. Nagios and Zabbix can raise alarms

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Tue, Jan 24 2017, gordon chung wrote: > you mean, keep alarm history in aodh and also in panko if needed? i'm ok > with that. Yeah, IIRC there's an expirer in Aodh for alarm history based on TTL – that's enough. That should probably be replaced with just a hard limit on the number of history

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 24/01/17 03:05 PM, Julien Danjou wrote: > I think Aodh emits notifications when something happens so it can be in > Panko indeed. I don't think it'd be fair to force Panko to have (a > recent) history though. :) i'm going to add a work item (for anyone): allow multiple notification topics

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Tue, Jan 24 2017, gordon chung wrote: > just curious, why doesn't vitrage send an event to aodh (on the error > topic) in this case rather than get nova to do it? if you created an > event alarm in aodh to check for vitrage error events could it solve the > use case? i don't know if we

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 24/01/17 03:01 AM, Afek, Ifat (Nokia - IL) wrote: > We understood that Aodh aims to be OpenStack alarming service, which is much > more than an ‘engine of alarm evaluation’ (as you wrote in your comment in > gerrit). If I may describe another use case for generic alarms - of OPNFV >

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Tue, Jan 24 2017, Afek, Ifat (Nokia - IL) wrote: > Vitrage, and I assume that other projects, needs an “Alarm Manager”. The role > of an Alarm Manager is to store all alarms in the system, keep their history, > notify on changes, etc. Vitrage does not declare itself as an Alarm Manager, >

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

Hi Julien, Before I reply to everything you wrote, I would like to ask a question that seems to be the core issue here. On 24/01/2017, 12:58, "Julien Danjou" wrote: On Tue, Jan 24 2017, Afek, Ifat (Nokia - IL) wrote: > We understood that Aodh aims to be OpenStack

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Tue, Jan 24 2017, Afek, Ifat (Nokia - IL) wrote: Hi Ifat, > We understood that Aodh aims to be OpenStack alarming service, which is much > more than an ‘engine of alarm evaluation’ (as you wrote in your comment in > gerrit). Well, currently it's not really more than that. We've been to the

[openstack-dev] [aodh][vitrage] Aodh generic alarms

Hi Julien, I’m sending this mail regarding the generic alarm that Alexey Weyl from the Vitrage team is trying to implement in Aodh [1][2]. We understood that Aodh aims to be OpenStack alarming service, which is much more than an ‘engine of alarm evaluation’ (as you wrote in your comment in

Re: [openstack-dev] [aodh] about alarm update with --query

On Tue, Nov 29 2016, dong.wenj...@zte.com.cn wrote: Hi dongwenjuan, I'd suggest to open a bug against aodh on Launchpad. I've no idea if it's a bug or not, but at least it'll be logged and we'll be able to dig into that. :) > Hi all, > > I use aodh cli to create a event alarm with query

[openstack-dev] [aodh] about alarm update with --query

Hi all, I use aodh cli to create a event alarm with query condition, the cli runs successfully. But when i want to update the query condition, the cli runs failed. The help info about `--query` para with these two cli have no difference. The information is as follows, Does anyone else know

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On Mon, Sep 26 2016, Zhai, Edwin wrote: > Do you have any idea to resolve this race condition? So following our discussion at the summit, I went ahead and wrote a spec about that feature: https://review.openstack.org/#/c/395058/ Comments are welcome obviously! Cheers, -- Julien Danjou #

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On Fri, 23 Sep 2016, gordon chung wrote: On 23/09/2016 2:18 AM, Zhai, Edwin wrote: There are many targets(topics)/endpoints in above ceilometer code. But in AODH, we just have one topic, 'alarm.all', and one endpoint. If it is still multi-threaded, there is already potential race condition

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 23/09/2016 2:18 AM, Zhai, Edwin wrote: > > There are many targets(topics)/endpoints in above ceilometer code. But > in AODH, we just have one topic, 'alarm.all', and one endpoint. If it is > still multi-threaded, there is already potential race condition here, > but event-alarm tiemout make

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 23/09/2016 3:19 AM, Zhai, Edwin wrote: > "Each notification listener is associated with an executor which > controls how incoming notification messages will be received and > dispatched. By default, the most simple executor is used - the blocking > executor. This executor processes inbound

Re: [openstack-dev] [AODH] event-alarm timeout discussion

Just check oslo messaging doc, don't know if it's out of date. "Each notification listener is associated with an executor which controls how incoming notification messages will be received and dispatched. By default, the most simple executor is used - the blocking executor. This executor

Re: [openstack-dev] [AODH] event-alarm timeout discussion

Thanks for your clarification, see my comments below. On Thu, 22 Sep 2016, gordon chung wrote: On 22/09/2016 2:40 AM, Zhai, Edwin wrote: See https://github.com/openstack/aodh/blob/master/aodh/evaluator/event.py#L158 evaluate_events is the handler of the endpoint for 'alarm.all', it

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 22/09/2016 2:40 AM, Zhai, Edwin wrote: > > See > https://github.com/openstack/aodh/blob/master/aodh/evaluator/event.py#L158 > > evaluate_events is the handler of the endpoint for 'alarm.all', it > iterates the event list and evaluate them one by one with project > alarms. If both

Re: [openstack-dev] [AODH] event-alarm timeout discussion

Gordon, Thanks for your comments. Pls. check my answer and flow chart below. On Wed, 21 Sep 2016, gordon chung wrote: === event-alarm timeout implementation = As it's for event-alarm, we need keep it as event-driven. Furthermore, for quick response, we need use event for

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 21/09/16 01:43 AM, Zhai, Edwin wrote: > All, > > I'd like make some clarification for the event-alarm timeout design as > many of you have some misunderstanding here. Pls. correct me if any > mistakes. > > I realized that there are 2 different things, but we mix them sometime: > 1.

[openstack-dev] [AODH] event-alarm timeout discussion

All, I'd like make some clarification for the event-alarm timeout design as many of you have some misunderstanding here. Pls. correct me if any mistakes. I realized that there are 2 different things, but we mix them sometime: 1. event-timeout-alarm This is one new type of alarm that bracket

Re: [openstack-dev] [Aodh] Ordering Alarm severity on context

On Tue, Jun 14 2016, gordon chung wrote: > for me, my concern is whether there's a strong desire to have ordering of > severity to be done based on context vs alphabetically, as it does now. if we > want ordering to be done by context, the followup would be whether we want to > support additional

Re: [openstack-dev] [Aodh] Ordering Alarm severity on context

important). cheers, -- gord From: Mike Carden <mike.car...@gmail.com> Sent: June 14, 2016 6:14:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Aodh] Ordering Alarm severity on context Hi S

Re: [openstack-dev] [Aodh] Ordering Alarm severity on context

Hi Sanjana and welcome to openstack-dev. Having sent all of us your 'Hitachi1' password, you may want to change that. :) In general, fishing for code reviews via the openstack-dev mailing list is a poor strategy. You may be better served by discovering the preferred communication channel(s) for

Re: [openstack-dev] [Aodh] Ordering Alarm severity on context

From: Sanjana Pai Nagarmat Sent: Tuesday, June 14, 2016 9:46 AM To: openstack-dev@lists.openstack.org Subject: [Aodh] Hi All, This is with respect to the bug https://launchpad.net/bugs/1452254 , which orders the severity of alarms based on context rather than sorting it alphabetically. My

[openstack-dev] [Aodh]

Hi All, This is with respect to the bug https://launchpad.net/bugs/1452254 , which orders the severity of alarms based on context rather than sorting it alphabetically. My code is out for review at https://review.openstack.org/#/c/328230 . I would like to know your opinion, on the approach I

Re: [openstack-dev] [aodh] Tempest gate not working

ilto:t...@bakeyournoodle.com] > Sent: Wednesday, May 25, 2016 1:11 PM > To: openstack-dev@lists.openstack.org; Mibu Ryota(壬生 亮太) > Subject: Re: [openstack-dev] [aodh] Tempest gate not working > > On Tue, May 24, 2016 at 04:50:21PM +0200, Julien Danjou wrote: > > Hi, > > > &g

Re: [openstack-dev] [aodh] Tempest gate not working

On Tue, May 24, 2016 at 04:50:21PM +0200, Julien Danjou wrote: > Hi, > > So it turns out we tried (especially Ryota) to add Tempest support via > https://review.openstack.org/#/c/303921/ for Aodh's gate, but it does > not actually run Tempest. Your gate scripts didn't like tempest as an enabled

Re: [openstack-dev] [aodh] Tempest gate not working

Julien, Thank you for the heads up. I'll check aodh tempest tests, and also drop tempest full tests in ceilometer since the code for ceilometer was removed from tempest. BR, Ryota > -Original Message- > From: Julien Danjou [mailto:jul...@danjou.info] > Sent: Tuesday, May 24, 2016

Re: [openstack-dev] [aodh] Tempest gate not working

Hi, Thanks for this mail, I also noticed that yesterday, and I am trying to fix it by https://review.openstack.org/#/c/320378/ cheers, Liusheng 在 2016/5/24 22:50, Julien Danjou 写道: Hi, So it turns out we tried (especially Ryota) to add Tempest support via

[openstack-dev] [aodh] Tempest gate not working

Hi, So it turns out we tried (especially Ryota) to add Tempest support via https://review.openstack.org/#/c/303921/ for Aodh's gate, but it does not actually run Tempest. Otherwise, we would have notice something wrong in https://review.openstack.org/#/c/318052/. As EmilienM noticed in Puppet

Re: [openstack-dev] [aodh] HBase gate job

On Tue, Nov 17 2015, ZhiQiang Fan wrote: > I prefer to deprecate all drivers except sql, but the upgrade issue > requires us providing some tools to migrate those existent data It does not require us anything if nobody steps us to do it. :) -- Julien Danjou ;; Free Software hacker ;;

Re: [openstack-dev] [aodh] HBase gate job

let's change this gate to experimental for now. On 17/11/15 05:10 AM, Julien Danjou wrote: Hi, So we recently decided to run the functional tests for the HBase driver and enabled the gate job. It turned out the gate job didn't worked, so I tried to fix it. Now it's almost fixed, and it run the

Re: [openstack-dev] [aodh] HBase gate job

On Tue, Nov 17 2015, Nadya Shakhat wrote: > Sorry I missed the letter. I'll take a look on this. As I understand, it's > enough just to run functional tests to see the issue, right? Yes, with my patch it should be pretty easy to reproduce. -- Julien Danjou -- Free Software hacker --

Re: [openstack-dev] [aodh] HBase gate job

Hi folks, Sorry I missed the letter. I'll take a look on this. As I understand, it's enough just to run functional tests to see the issue, right? Nadya On Tue, Nov 17, 2015 at 4:48 PM, gord chung wrote: > let's change this gate to experimental for now. > > On 17/11/15 05:10 AM,

Re: [openstack-dev] [aodh] HBase gate job

I prefer to deprecate all drivers except sql, but the upgrade issue requires us providing some tools to migrate those existent data On Tue, Nov 17, 2015 at 6:10 PM, Julien Danjou wrote: > Hi, > > So we recently decided to run the functional tests for the HBase driver > and

[openstack-dev] [aodh] HBase gate job

Hi, So we recently decided to run the functional tests for the HBase driver and enabled the gate job. It turned out the gate job didn't worked, so I tried to fix it. Now it's almost fixed, and it run the functional tests and Gabbi tests against Aodh with HBase as a back-end:

Re: [openstack-dev] [aodh][ceilometer] (re)introducing Aodh - OpenStack Alarming

Hi, Gord, Good to know there will be a team dedicated to this alarming service. After reading your email, I still feel a need for some clarifications. - According to [1], Aodh will be released as a standalone service, am I understanding this correctly? - What is the official name for this new

Re: [openstack-dev] [aodh][ceilometer] (re)introducing Aodh - OpenStack Alarming

On Wed, Sep 09 2015, Qiming Teng wrote: > - According to [1], Aodh will be released as a standalone service, > am I understanding this correctly? Yes. > - What is the official name for this new serivce when it stands on its > own feet: "Telemetry Alarming" or just "Alarming" or something

[openstack-dev] [aodh][ceilometer] (re)introducing Aodh - OpenStack Alarming

hi all, as you may have heard, in an effort to simplify OpenStack Telemetry (Ceilometer) and streamline it's code, the alarming functionality provided by OpenStack Telemetry has been moved to it's own repository[1]. The new project is called Aodh[2]. the idea is that Aodh will grow as it's

[openstack-dev] [Aodh][Gnocchi] Change of Launchpad ownership

Hi folks, Per recent discussion with the team, and to reflect the fact that we have different core reviewers group on Gerrit for Ceilometer/Gnocchi/Aodh, I've implemented the same arrangements on Launchpad. There are now 2 new teams: https://launchpad.net/~aodh-drivers