Ceilometer Alarm resource has only 'matching_metadata' NOT general 'query'

[Qiming Teng]

In Ceilometer (client), the API to create a threshold alarm has changed.

The previous 'matching_metadata' parameter is deprecated. The OS::Ceilometer::Alarm resource should now use the 'query' parameter for meter filtering.

The heat problem is that currently it can create alarms that filter only based on metadata, but there are other Sample attributes that are desirable for use in filtering --- such as resource_id.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/98327

[OpenStack Infra (hudson-openstack)]

Change abandoned by Qiming Teng (<email address hidden>) on branch: master
Review: https://review.openstack.org/98327
Reason: This change is abandoned due to ceilometerclient is not ready to parse 'query' parameter.

[Mike Spreitzer (mike-spreitzer)]

In particular, there is no way to use Heat to create a Ceilometer alarm that filters samples based on the associated resource_id. This is a real problem, because such filtering is part of the simplest pattern for health maintanence.

[Mike Spreitzer (mike-spreitzer)]

See https://review.openstack.org/#/c/124656/ for something that suffers from this bug.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/127821

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/127821
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=0c50b7d23f5cd5c3cd0b35a563a6b602986d1c09
Submitter: Jenkins
Branch: master

commit 0c50b7d23f5cd5c3cd0b35a563a6b602986d1c09
Author: Mike Spreitzer <email address hidden>
Date: Sat Oct 11 22:30:20 2014 +0000

    Add query property to threshold alarms.

    Heat had fallen behind the evolution of the Ceilometer API. The full
    generality of the Ceilometer API for creating alarms was not available
    through Heat templates. In particular, the template author could
    stipulate only matching metadata in the query for Samples; other very
    interesting attributes, such as resource_id, could not be referenced
    in alarm properties.

    This change introduces a new property for OS::Ceilometer::Alarm,
    namely "query". The template can now specify a query property instead
    of a matching_metadata property, and can thus reference anything that
    can be referenced in a Ceilometer query.

    The old matching_metadata property remains, and its constraints on
    which samples to accept are combined with those from the query (if
    any).

    Note also that the python-ceilometerclient has a lot of backward
    compatibility logic --- including accepting matching_metadata. This
    change adds all that logic into OS::Ceilometer::Alarm, so that it
    becomes a proper client of the current Ceilometer API.

    Closes-Bug: #1326721
    Change-Id: I0667db868c6f827867a5a20e4a3fa22fcad1a6a1

[Matt Riedemann (mriedem)]

In order to backport this to stable/juno, two other fixes have to be squashed with the backport due to regressions introduced with the original fix:

https://github.com/openstack/heat/commit/a0ffafdf8eaa751b792c5f9628eac20a8800c8b5

And:

https://github.com/openstack/heat/commit/bd3078e67812d51fa38dce17dd1009bad1613ad2

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/146624

[Steven Hardy (shardy)]

I think a concrete example of why this is needed for Juno would be helpful, e.g so we can justify the backport as strictly speaking it's both a feature and a new interface, so probably wouldn't normally be considered valid for a stable backport.

That said, if some obviously needed use-case is impossible on Juno because of this ommision, I think it's reasonable to say it's in the best interests of users to backport it (particularly if we're satisfied it's totally backwards compatible and would not adversely affect any existing users/templates on Juno.

Can anyone provide a more detailed example of where a query is needed for resource that don't have metadata associated?

[Thomas Spatzier (thomas-spatzier)]

I think the mail thread below gives an example and indicates that some users would like to see a backport:

http://lists.openstack.org/pipermail/openstack-dev/2015-January/054902.html

[OpenStack Infra (hudson-openstack)]

Change abandoned by Matt Riedemann (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/146624
Reason: Not worth it, agree with Ihar and Jay. If someone needs this on Juno they can pull it from here, part of this was just going through the work of seeing how I could put this together with the various commits squashed and removing the version support dependency. After a couple of hours of doing it in the right order to make it work I figured it'd be a waste not to push it up for review, but agree it's not appropriate for stable.