Help with Intrinsic functions

[jbieberly-xumo]

I am attempting to build a test template for a CloudFormation template that uses intrinsic functions to use values returned after resources are created to populate values needed for other resources in the same template. Here is what this part of my CloudFormation template looks like:
- Name: ENDPOINT_MPV2_2 Value: !Select [0, !GetAtt MediaPackageV2Channel.IngestEndpointUrls] - Name: ENDPOINT_MPV2_1 Value: !Select [1, !GetAtt MediaPackageV2Channel.IngestEndpointUrls]

This functionality works fine and the correct values get populated when I build a CloudFormation stack.

I've tried several methods to mock these URL values, none have been successful. I typically get an error like one of these, depending on what I try:
Error: IngestEndpointUrls property is missing from MediaPackageV2Channel resource.
Error: Fn::Select - The first value must be a Number and the second a List.

The failure always occurs at template.create_stack when running the test function.

Is there some documentation I should be referencing to figure this out? An example would be great!

[dhutchison]

Hey @jbieberly-xumo,

My best guess right now is that it isn't necessarily something you are doing wrong, but possibly an edge case either with ordering of intrinsic functions or how rendering of the AWS::MediaPackageV2::Channel type happens.

Would you be able to provide a bit more of the template, including the two involved resources so I can troubleshoot a bit better?

Thanks.

[jbieberly-xumo]

Here is the template portion that creates AWS::MediaPackageV2::Channel

MediaPackageV2Channel: Type: AWS::MediaPackageV2::Channel Properties: ChannelGroupName: dev_video_1 ChannelName: !Sub ${AWS::StackName}-MediaPackageChannel

As you can see, it is very basic, but the IngestEndpointUrls are returned after the channel is created. Then they can be accessed with this: Value: !Select [0, !GetAtt MediaPackageV2Channel.IngestEndpointUrls]

So I need a way to mock that value, since with cloud_radar it isn't actually creating the MediaPackageV2Channel and no URL would be returned.

I'm accessing the IngestEndpointUrls twice, once when I create an ECS task definition and once in the output of the CF stack. The ECS task definition has a bunch of stuff I probably shouldn't share, but the output looks like this:
Outputs: ClusterName: Description: The cluster used to create the service. Value: !Ref ECSClusterName ECSService: Description: The created service. Value: !Ref ECSService ChannelArn: Description: The ARN of the MediaPackageV2 Channel. Value: !GetAtt MediaPackageV2Channel.Arn ChannelCreatedAt: Description: The creation timestamp of the MediaPackageV2 Channel. Value: !GetAtt MediaPackageV2Channel.CreatedAt ChannelIngestEndpointUrl1: Description: The first IngestEndpointUrl of the MediaPackageV2 Channel. Value: !Select [0, !GetAtt MediaPackageV2Channel.IngestEndpointUrls] ChannelIngestEndpointUrl2: Description: The second IngestEndpointUrl of the MediaPackageV2 Channel. Value: !Select [1, !GetAtt MediaPackageV2Channel.IngestEndpointUrls]

[dhutchison]

Thanks for that - it'll help diagnose things a bit better.

Probably won't be till next week though until I can get a look at it. Got a crazy amount of things to get done this week.

[dhutchison]

So the quick (and minimal) investigation I've done in to this today is that the GetAtt implementation in this library is a bit simplistic. What it returns is the string of {resource_name}.{att_name} - e.g. MediaPackageV2Channel.IngestEndpointUrls.

This is not doing any real rendering of what return values for CloudFormation resources could look like. For things that take strings the current implementation is good enough, it just falls down where other intrinsic functions are stacked.

Will swing back around in a few days and see if there are any reasonable solutions to make this work. I don't think we want to be in the position where we are adding to the library special cases for each resource type and consumers need to wait for new types to be supported, but then again do need some way to support it in these edge cases. I don't think I've came across many resource types that return list values.

[dhutchison]

The linked PR #399 contains a proposed solution to this edge case.