Closed dannosaur closed 4 years ago
Ok. I get that this might be necessary in the imported template...
Parameters:
ProjectName:
$global: true
Environment:
$global: true
Which does indeed resolve the above issue. However, if the parameter passed in to the resource isn't a CFN stack parameter (for instance, if I'm referencing another resource, like if I have a memcached resource that I import multiple times and need to address a specific one), then this happens in the rendered output;
Parameters:
# truncated for brevity
Table: {}
which then causes CFN to complain that the parameter needs at least a Type
attribute, which will then eventually demand that the parameter has a value.
So the way I see it, either imported !Ref
's need to not be prefixed when processing them, or the final Parameters
section in the output needs to filter out empty objects so that the $global
flag can be set without causing CFN to start demanding values for parameters that aren't stack parameters.
I think this is roughly the same issue as #105.
When using custom resources that make use of parameters, when those parameters are references to CFN parameters (via
!Ref
), the values which have originated from a global section are prefixed, which then breaks the reference to the parameter.Take this example;
vpc.yml
stack.yml
The actual output is...
whereas I'd expect
!Ref ProjectName
and!Ref Environment
to remain untouched.Unless I'm missing something?