Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 987450

Summary: [RFE] Allow appropriate separation between metering & metric/alarms infrastructure
Product: Red Hat OpenStack Reporter: Eoghan Glynn <eglynn>
Component: openstack-ceilometerAssignee: Eoghan Glynn <eglynn>
Status: CLOSED CURRENTRELEASE QA Contact: Shai Revivo <srevivo>
Severity: high Docs Contact:
Priority: high    
Version: 4.0CC: jdanjou, jruzicka, sgordon, srevivo
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/ceilometer/+spec/alarming-metering-separation
Whiteboard: upstream_milestone_none upstream_status_informational upstream_definition_approved
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-29 13:13:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 986367    
Bug Blocks: 973191, 1055813    

Description Eoghan Glynn 2013-07-23 12:05:46 UTC 
The data acquisition underlying ceilometer alarming can by default share the same infrastructure as the existing metering functionality.

However in realistic deployments, we envisage that operators may want to reflect differing requirements by separating off the transport conduit and storage elements.

This requirement is largely addressed by a series of changes to enable smaller chunks of functionality:

* a non-AMQP conduit more suited to loss-tolerant metric data (addressed by the udp-publishing blueprint[1])

* a separate metrics store with roll-up functionality (the most extreme form of roll-up, i.e. time-to-live[2], will suffice for Havana)

* transformers to use a sampling approach to convert the cumulative instance meters to equivalent guage values which are far more useful for alarming (addressed by the transformer-unit blueprint[3], BZ #986367)

Hence this BZ is just intended to act as a placeholder for the upstream blueprint[4], and to capture the testing/QE requirements.

[1] https://blueprints.launchpad.net/ceilometer/+spec/udp-publishing
[2] https://blueprints.launchpad.net/ceilometer/+spec/db-ttl
[3] https://blueprints.launchpad.net/ceilometer/+spec/transformer-unit
[4] https://blueprints.launchpad.net/ceilometer/+spec/alarming-metering-separation
Comment 4 Julien Danjou 2016-07-29 13:13:51 UTC 
All the blueprint listed above were implemented upstream these last years. Closing.