This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 987450 - [RFE] Allow appropriate separation between metering & metric/alarms infrastructure
[RFE] Allow appropriate separation between metering & metric/alarms infrastru...
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-ceilometer (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Eoghan Glynn
Shai Revivo
upstream_milestone_none upstream_stat...
: FutureFeature
Depends On: 986367
Blocks: 973191 1055813
  Show dependency treegraph
Reported: 2013-07-23 08:05 EDT by Eoghan Glynn
Modified: 2016-07-29 09:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-07-29 09:13:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
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
OpenStack gerrit 30100 None None None Never
OpenStack gerrit 30273 None None None Never
OpenStack gerrit 30635 None None None Never

  None (edit)
Description Eoghan Glynn 2013-07-23 08:05:46 EDT
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.

Comment 4 Julien Danjou 2016-07-29 09:13:51 EDT
All the blueprint listed above were implemented upstream these last years. Closing.

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