[AWS::CloudFormation::WaitConditionSignal] - [Enhancement] - Allow WaitConditions to be signaled in a template

[ironiridis]

Name of the resource

AWS::CloudFormation::WaitConditionHandle

Resource name

No response

Description

There are cases where it's not possible to directly convey an architecture in a template without workarounds, like in #523 -- my solution to this cross-region ARN handoff relies on a quirk of Secret replication within a StackSet. This would not be usable cross-account (at least, not without quite a lot more scaffolding in the template) and is probably too fragile to rely on.

I'm picturing two related changes:

Implement WaitConditionSignal

It should be possible to have a pseudo-resource that sends a signal payload to a WaitConditionHandle. Something like:

Resources:
  CDNCertificateARN:
    Type: AWS::CloudFormation::WaitConditionSignal
    Properties:
      Handle: !Ref CDNCertificateWait
      Value: !Ref CDNCertificate

This would provide a cross-account and cross-region mechanism to cleanly supply a waiting resource with an attribute (such as a randomly generated ID) in the parent stack to a StackSet.

Because a wait condition signal can contain either a success or a failure condition, it may make sense to have a special case where a Stack with a WaitConditionSignal pending creation or update (ie has not yet signaled), if that stack creation or update fails, the Handle is signaled with a failure as well. This would only make sense if the Handle was already resolved, of course.

Improve WaitConditionHandle

Currently, WaitConditionHandle does not carry any properties. A related-to-the-above but independent improvement to this resource would be to add an array property Watch (better names welcome) such that any change to any array values causes a new Handle to be generated, updating the resource. This neatly solves one usability issue: updates to waited-on resources can now re-signal on the new Handle to indicate readiness, so downstream wait-blocked resources can be sequenced accordingly. Watch would effectively define any parameters or attributes that invalidate downstream resources that would signal this Handle.

Resources:
  CDNCertificateWait:
    Type: AWS::CloudFormation::WaitConditionHandle
    Properties:
      Watch:
      - !Ref Route53ZoneId
      - !Ref Route53ZoneName
      - !Ref Subdomain

Of course, without any properties specified, the resource's behavior is unchanged; the Handle is generated once, when it is created.

Other Details

No response