Add support for Cloud Watch Alarm Tags

[gswai123]

This enhancement uses the augment function to add Tags to CloudWatch Alarm resources in Custodian, allowing users to filter by Alarm Tags using the Value Filter. The PR also includes a "Tag" action for CloudWatch alarms which allows users to add tags to alarm resources.

Issue Link: #6454

[kapilt]

lgtm, thanks

[PratMis]

I think we may also need remove-tag, mark-for-op and marked-for-op. Would it be better to just use universal_taggble?

[kapilt]

Thanks that’s a good call, to get all the tag filter/actions for free so to speak.

…

On Thu, Apr 1, 2021 at 4:51 PM Pratyush Mishra ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In c7n/resources/cw.py <#6598 (comment)> : > @@ -37,6 +45,35 @@ class resource_type(TypeInfo): cfn_type = config_type = 'AWS::CloudWatch::Alarm' retry = staticmethod(get_retry(('Throttled',))) + source_mapping = { + 'describe': DescribeAlarm, + 'config': ConfigSource + } + + ***@***.***_registry.register('tag') I think we may also need remove-tag, mark-for-op and marked-for-op. Would it be better to just use universal_taggble? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#6598 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFJERML56RHYZYKGQPBTTTGTMERANCNFSM42HVX7MQ> .

[PratMis]

Only thing I can see here is that, Tags are not getting captured with source: config. AWS claims to be capturing the tags re: config cmdb(https://github.com/awslabs/aws-config-resource-schema/blob/e7586bdfd24f31427ccc8df21d760670bbcd1d93/config/properties/resource-types/AWS::CloudWatch::Alarm.properties.json), but it doesn't show up in reality

Response captured with config as source:

{'resourceId': 'c7n-test-alarm-tags-filter', 'configuration': {'Statistic': 'Average', 'Period': 3600.0, 'MetricName': 'CPUUtilization', 'ComparisonOperator': 'GreaterThanThreshold', 'AlarmConfigurationUpdatedTimestamp': datetime.datetime(2021, 3, 24, 18, 1, 32, 583000, tzinfo=tzutc()), 'AlarmName': 'c7n-test-alarm-tags-filter', 'Threshold': 10.0, 'Okactions': [], 'InsufficientDataActions': [], 'EvaluationPeriods': 5.0, 'ActionsEnabled': True, 'Namespace': 'AWS/EC2', 'Metrics': [], 'AlarmActions': [], 'AlarmArn': 'arn:aws:cloudwatch:us-east-1:644160558196:alarm:c7n-test-alarm-tags-filter', 'Dimensions': []}, 'supplementaryConfiguration': {}}

vs boto response:

[
  {
    "AlarmName": "c7n-test-alarm-tags-filter",
    "AlarmArn": "arn:aws:cloudwatch:us-east-1:644160558196:alarm:c7n-test-alarm-tags-filter",
    "AlarmConfigurationUpdatedTimestamp": "2021-03-24T18:01:32.583000+00:00",
    "ActionsEnabled": true,
    "OKActions": [],
    "AlarmActions": [],
    "InsufficientDataActions": [],
    "StateValue": "INSUFFICIENT_DATA",
    "StateReason": "Unchecked: Initial alarm creation",
    "StateUpdatedTimestamp": "2021-03-24T18:01:32.583000+00:00",
    "MetricName": "CPUUtilization",
    "Namespace": "AWS/EC2",
    "Statistic": "Average",
    "Dimensions": [],
    "Period": 3600,
    "EvaluationPeriods": 5,
    "Threshold": 10.0,
    "ComparisonOperator": "GreaterThanThreshold",
    "Tags": [
      {
        "Key": "OwnerName",
policies:
        "Value": "SomeName"
      },
      {
        "Key": "pratyush",
        "Value": "test"
      },
      {
        "Key": "some-tag",
        "Value": "some-value"
      }
    ]
  }
]

[kapilt]

re config, the last few prs on config support, i'm noticing there's pretty large variance on the number of important resource data they fail to capture. any issues with config data capture, are definitely something to take up directly with the service team via tam, its not something we can really handle. we can note those deficiets in the resource doc string is probably the best we can do, but its probably something that can age out.

[PratMis]

re config, the last few prs on config support, i'm noticing there's pretty large variance on the number of important resource data they fail to capture. any issues with config data capture, are definitely something to take up directly with the service team via tam, its not something we can really handle. we can note those deficiets in the resource doc string is probably the best we can do, but its probably something that can age out.

Yup, making a note of these so that I can bring it up to our TAM. Thanks @kapilt

[kapilt]

lgtm, thanks