Pass in "Extra" Values

[taylorbartley]

Feature Request

I'd like to be able to pass in values for additional properties to the MODULE types.

Example for a module named ACME::FOO::LogGroup::MODULE:

Parameters:
  FunctionName:
    Type: String

Resources:
  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/lambda/${FunctionName}

Example use case of a default property as defined by CloudFormation/API:

LogGroup:
    Type: ACME::FOO::LogGroup::MODULE
    Properties:
      FunctionName: !Ref SomeLambdaFunction
      RetentionInDays: 3 << "Default" Property.

[taylorbartley]

I've just learned of the resource providers repository.

I can migrate this request there if it's more appropriate.

[MalikAtalla-AWS]

Hey Taylor. Thanks for raising this. How would the RetentionInDays be used in this scenario? Is the idea that it matches a name of a property of LogGroup and is applied directly to that resource?

[taylorbartley]

@MalikAtalla-AWS That's exactly the use case! Since RetentionInDays is already a predefined property, it'd be nice to set that in the CFT template and have it passed through to the module, even if the module doesn't expose that property as a parameter.

Another example could be LambdaFunction module, where Runtime, Type, etc., are all passed in as parameters, but in the CFT template you also added Environment Variables as well.

[PatMyron]

Could get ambiguous for modules with multiple resources, so this might break if the module ever gets another resource

[taylorbartley]

Right. I'm sure there would also be the complication of what happens when, for LogGroups, the module does define RetentionInDays?

[MalikAtalla-AWS]

Yes, so this mechanism wouldn't work exactly as is, but I think I see what you're trying to achieve. You're trying to override certain properties of a module that are not exposed as parameters. This is a legitimate use case and is something we have discussed in the team before. I can pass this on as a data point to our product managers.

[benbridts]

I understand the use case (it is very tempting to use modules to set your own defaults), but I personally would recommend against doing this.

• It makes it significantly harder to know the configuration of what will be deployed because you need to look at both the AWS documentation and the module documentation (or even source code).
• The ACME::FOO::LogGroup::MODULE might not be used in other modules you're writing, and that's hard to see form the top-level
• ACME::FOO::LogGroup::MODULE will definitely not be used in modules that are shared as Open Source projects
• Other Companies are running into this issue too

If you want more background on that, here are some links for possibly diving deeper

• I talked a bit about the problems I had with this approach in my talk at the CDK day (the talk is CDK-specific, but the ideas are more general).\
• Another example of people warning against this is the "L2.5" constructs warning in this CDK RFC.. You don't need to read the whole thread, the linked comment and the comment after that have most of the information.

[taylorbartley]

@benbridts I really appreciate the extra info you included. To be clear, I do understand this was a very niche ask, and is probably outside the philosophical scope of modules in general. I mainly asked out of curiosity to see how far we could extend them. I'm satisfied with the dialog. Whoever's in charge, please feel free to close or resolve this issue thank you!