Specify properties for serialized behavior

[benkehoe]

I'd like to create an AWS::S3::BucketNotification resource to fix a longstanding problem in CloudFormation. And when I do, I'd like to enable individual notification configuration items to be managed separately. But because the API only supports updating the entire notification configuration, I need to serialize access to the notification configuration for a given bucket. I plan to do with a resource provider that relies on a user-account-side mechanism involving an SQS FIFO queue. It would be great if, in my schema, I could specify a property or set of properties that would cause all resources with the same values for those properties to have their requests serialized (but resources with different values for those properties could be processed in parallel).

[rjlohan]

I like this concept, it's going to take some thinking on how to support this in the service.

[benkehoe]

Another use case is that the CloudFormation type registry only allows one in-flight operation at a time on a given type. So if I have multiple AWS::CloudFormation::ResourceVersion resources with the same TypeName, I need to manually serialize those resources using DependsOn (example).

[benbridts]

Adding DynamoDB tables as a use case (from the docs):

AWS CloudFormation typically creates DynamoDB tables in parallel. However, if your template includes multiple DynamoDB tables with indexes, you must declare dependencies so that the tables are created sequentially. Amazon DynamoDB limits the number of tables with secondary indexes that are in the creating state. If you create multiple tables with indexes at the same time, DynamoDB returns an error and the stack operation fails.

[benkehoe]

Adding DynamoDB tables as a use case

This might be a separate request, as it is a global concurrency limit (possibly soft), rather than a strict serialization based on the value of a property or set of properties. I'm tempted to say such a concurrency limit belongs in the registry API rather than the schema.

[benbridts]

This might be a separate request

You're right. In cases where ordering doesn't matter Concurrency: 1 could also solve the serialization (if it can be currently solved with DependsOn).

@rjlohan If i create a new ticket for that, should it go in the Coverage Roadmap?

[rjlohan]

This might be a separate request

You're right. In cases where ordering doesn't matter Concurrency: 1 could also solve the serialization (if it can be currently solved with DependsOn).

@rjlohan If i create a new ticket for that, should it go in the Coverage Roadmap?

Yeah put it there. It'll require at least some service side changes to understand the directive whether it comes from template or type schemas.