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
All the blueprint listed above were implemented upstream these last years. Closing.