cf.dereference()

[rclark]

A method that would take:

• env: object defining values for psuedo parameters like AWS::StackName
• parameters: object defining values for parameters
• template: a template

Would return the template with all psuedo parameters and intrinsic functions dereferenced.

cc @ianshward @k-mahoney

[rclark]

I got the logic working here, but there's an extremely tedious busywork step that remains. In order to dereference Fn::GetAtt and Ref against resources, you need to know what Ref refers to and what attributes are available for Fn:GetAtt for each resource type.

Resource types, and an example of the Return Values section.

I wrote an HTML scraper, scraped the docs and built a JSON file that isolates the text from Return Values sections for each type, but its not consistent enough to automate conversion --> the JS code needed.

I think I'll just have to prioritize and chip away at the types over time.

[rclark]

@k-mahoney @ianshward for your purposes, how accurate do resource dereferences need to be? For example, let's say my resource defines an SQS queue.

{ "Fn::GetAtt" :["MyQueue", "QueueName"] }

This is supposed to give you the name of the queue. If the JSON defining the queue itself included a .Properties.Name value, then we can know exactly what the queue's name will be. But if you didn't specify that property, CloudFormation would assign a name something like:

MyStack-MyQueue-1A2B3C4D

Most of the time, resources don't let you assign a .Properties.Name, so most of the time, we can't really honestly resolve a { "Ref": "SomeThing" }. If we're trying to dereference all the values in the template prior to the template being deployed, there's no way for us to know the random string that CloudFormation will assign to the resource.

Is this important for your use case?

[k-mahoney]

Thanks again for taking this on @rclark! Still working through wrapping my head around #14.

The dereferencing function as it stands should work well with our proposed use case and the changes we need to make for testing. I don't think expanding coverage for all the assorted resource attributes is critical at this juncture, but I'm happy to contribute on that front if I can.

Hadn't considered the issue of attempting to reference specific IDs generated upon deployment prior to doing so, that's an interesting problem... not a requirement for our use case though.

[rclark]

We moved in other directions here.