Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1346366 - Expose parameter for enabling AODH-Event alarms
Expose parameter for enabling AODH-Event alarms
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates (Show other bugs)
9.0 (Mitaka)
Unspecified Unspecified
unspecified Severity unspecified
: Upstream M3
: 11.0 (Ocata)
Assigned To: Pradeep Kilambi
Sasha Smolyak
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-14 11:48 EDT by Yurii Prokulevych
Modified: 2017-05-17 15:31 EDT (History)
10 users (show)

See Also:
Fixed In Version: openstack-tripleo-heat-templates-6.0.0-0.20170130212245.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-05-17 15:31:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1590473 None None None 2016-06-14 11:48 EDT
OpenStack gerrit 409931 None None None 2017-01-13 09:30 EST
Red Hat Product Errata RHEA-2017:1245 normal SHIPPED_LIVE Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory 2017-05-17 19:01:50 EDT

  None (edit)
Description Yurii Prokulevych 2016-06-14 11:48:57 EDT
Description of problem:
-----------------------
Enabling events-alarm-evaluator is a bit tricky.
It would be great to have a parameter that if enabled configures all the parts.

The main parts are:
 - store_events enabled in ceilometer.conf
 - Event evaluator binds to queue (default alarm.all)
 - events are dispatched to AODH's evaluator and to Ceilometer's storage backend.

---
Yurii
Comment 2 Julien Danjou 2016-12-09 09:31:27 EST
- Store_events has been removed and is automatically enabled if events pipeline is not empty
- Event evaluator binds to queue (default alarm.all) -> I think this is the default right?
- events are dispatched to AODH's evaluator and to Ceilometer's storage backend. -> so we can change the default to do that, *however*, if we do it by default and Aodh is not there running, RabbitMQ will explode. So I am not sure it's a good idea.

Hint? Idea? Is this enough Yurii?
Comment 3 Yurii Prokulevych 2016-12-09 09:49:14 EST
Hi Julien,

So the original idea for the bz is to have a flag exposed to operator, which when enabled - configures all the aforementioned pieces.

Looks it has to be assigned for another component - director/t-h-t/...

Prad, since U are assignee on the upstream bz, could U please update the component?
Comment 4 Pradeep Kilambi 2016-12-09 11:48:40 EST
I think last jd and i discussed this, We wanted all of this to happen in aodh/ceilometer itself, without any tweaks in tripleo. From what jd said above in comment#2 looks like its already taken care of in Aodh and Ceilometer?
Comment 5 Julien Danjou 2016-12-12 08:15:17 EST
The only thing that cannot be done automatically by Ceilometer upstream is "Event evaluator binds to queue (default alarm.all)"

This should only be done if Aodh is enabled, by since Aodh is just a consumer of what Ceilometer might produce, there's no way to detect that.

So this should be enabled by TripleO when it sees that both Ceilometer and Aodh are configured together.

How does that sound Prad?
Comment 6 Pradeep Kilambi 2016-12-12 10:42:07 EST
(In reply to Julien Danjou from comment #5)
> The only thing that cannot be done automatically by Ceilometer upstream is
> "Event evaluator binds to queue (default alarm.all)"
> 
> This should only be done if Aodh is enabled, by since Aodh is just a
> consumer of what Ceilometer might produce, there's no way to detect that.
> 
> So this should be enabled by TripleO when it sees that both Ceilometer and
> Aodh are configured together.
> 
> How does that sound Prad?

sure we can do that in puppet. We always configure aodh, so we can set the event_alarm_topic.
Comment 9 errata-xmlrpc 2017-05-17 15:31:06 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1245

Note You need to log in before you can comment on or make changes to this bug.