Bug 1042346 - [RFE][ceilometer]: Event Pipelines
Summary: [RFE][ceilometer]: Event Pipelines
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-ceilometer
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Upstream M2
: 7.0 (Kilo)
Assignee: Eoghan Glynn
QA Contact: Yurii Prokulevych
URL: https://blueprints.launchpad.net/ceil...
Whiteboard: upstream_milestone_kilo-2 upstream_st...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 21:49 UTC by RHOS Integration
Modified: 2015-08-05 13:11 UTC (History)
7 users (show)

Fixed In Version: openstack-ceilometer-2015.1.0-2.el7ost
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-05 13:11:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:1548 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2015-08-05 17:07:06 UTC

Description RHOS Integration 2013-12-12 21:49:31 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/ceilometer/+spec/notification-pipelines.

Description:

There currently exists pipelines in Ceilometer for Sample data. This would extent the current pipeline mechanism to allow for pipelines for Notification/Event data.

The event pipelines would have their own namespace for transformers , etc.

The transformers in these pipelines could alter/extend events, filter, synthesize new events, and generate Sample data from events (integrating the existing notification plugin mechanism) to feed to the Sample pipelines.

Specification URL (additional information):

None

Comment 3 Yurii Prokulevych 2015-04-08 10:25:21 UTC
Hi Eoghan,

Some questions regarding the RFE:

1. Events still received by ceilometer-agent-notification service but processed according to event_pipeline.yaml conf file or event_definitions.yaml, or both?
2. If event_pipeline.yaml is missing - some default configuration is used?
    As with events_definitions.yaml - if it's missing a warning is logged, but an empty set of definitions is assumed
3. Is event_pipeline.yaml installed as part of ceilometer* rpm?
4. 'store_events' option from ceilometer.conf['notification'] - does it affect configuration defined within event_pipeline.yaml?
5. event_definitions.yaml and event_pipeline.yaml do they work in parallel or they are run in some strictly defined order?
    For e.g: 1tly event_definitions.yaml and then event_pipeline.yaml or vice versa?
6. does 'drop_unmatched_notification' option affects 'event_pipeline.yaml' processing?
7. Do 'event_definitions.yaml' and 'event_pipeline.yaml' share the same DB for storage?
8. event_pipeline.yaml - configuration format:
    -- what are available publishers?
    -- what are available transformers?
    -- triggers? what are they used for? how are they configured?
9. Can events processed according to event_definitions.yaml and event_pipeline.yaml be stored in different DBs? Different backends - MongoDB, MySQL?
10. Currently to convert some notifications to meters pipeline.yaml is used. What file is used with new event processing model: event_pipeline.yaml or still pipeline.yaml?
11. How are events not defined within event_pipeline.yaml conf file handled - dropped, processed?

Thanks,
Yurii

Comment 4 gchung 2015-05-04 14:22:00 UTC
1. Events still received by ceilometer-agent-notification service but processed according to event_pipeline.yaml conf file or event_definitions.yaml, or both?
 - both. event_definitions.yaml will index specific attributes from notification and allow them to be queryable via ceilometer-api. event_pipeline.yaml is used similar to pipeline.yaml (filters, publishes)
2. If event_pipeline.yaml is missing - some default configuration is used?
    As with events_definitions.yaml - if it's missing a warning is logged, but an empty set of definitions is assumed
 - you need event_pipeline.yaml if you enable events
3. Is event_pipeline.yaml installed as part of ceilometer* rpm?
 - no clue? but it should.
4. 'store_events' option from ceilometer.conf['notification'] - does it affect configuration defined within event_pipeline.yaml?
 - yes, anything event related -- event_definition, event_pipeline -- is irrelevant if you don't enable store_events
5. event_definitions.yaml and event_pipeline.yaml do they work in parallel or they are run in some strictly defined order?
    For e.g: 1tly event_definitions.yaml and then event_pipeline.yaml or vice versa?
 - event_definition is use first and then the results are passed to event_pipeline logic
6. does 'drop_unmatched_notification' option affects 'event_pipeline.yaml' processing?
 - yes, if you have the option enabled and don't have a notification defined in event_definition, the notificatin won't get processed regardless if you enable it in pipeline.
7. Do 'event_definitions.yaml' and 'event_pipeline.yaml' share the same DB for storage?
 - n/a, event_definition just does processing of notification, event_pipeline controls where data is sent/stored
8. event_pipeline.yaml - configuration format:
    -- what are available publishers?
          - same as pipeline.yaml
    -- what are available transformers?
          - n/a for kilo
    -- triggers? what are they used for? how are they configured?
          - n/a for kilo
9. Can events processed according to event_definitions.yaml and event_pipeline.yaml be stored in different DBs? Different backends - MongoDB, MySQL?
 - yes. you can technically publish to two different queues using notifier publihser. from that, you can have two collectors that consume from one of the queues and point to different dbs,
10. Currently to convert some notifications to meters pipeline.yaml is used. What file is used with new event processing model: event_pipeline.yaml or still pipeline.yaml?
 - event_pipeline.yaml
11. How are events not defined within event_pipeline.yaml conf file handled - dropped, processed?
 - the event_pipeline.yaml filters everything it receives.

Comment 10 Yurii Prokulevych 2015-06-25 14:07:44 UTC
Verified according to test plan.

Comment 12 errata-xmlrpc 2015-08-05 13:11:12 UTC
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-2015:1548


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