Simply, provide a way-forward whereby attempting to use the add*Command methods inherited from UserData do not throw exceptions. Rather, invoking the methods on MultipartUserData passes the invocation through to a designated UserData object.
Use Case
CDK construct libraries (like https://github.com/aws/aws-rfdk) allow the customer to provide a UserData object into an L3 construct. That L3 construct may use the provided UserData object in the creation of Instances, AutoScaling Groups, etc, but also use methods on the UserData such as addCommands(), addS3DownloadCommand(), etc to set up initialization required by the L3 construct.
Having these methods on the MultipartUserData throw exceptions makes it awkward at best to integrate the class with these libraries. Without this change to MultipartUserData these libraries would be required to accept both a UserData and MultipartUserData property to support MultipartUserData -- commands would be added to the UserData, but the MultipartUserData would be used to actually render the Instance/ASG's -- and enforce, somehow, that the given UserData is a part in the given MultipartUserData. It's all very awkward.
Proposed Solution
I have a candidate PR prepped, and will be posting it momentarily.
[x] :wave: I may be able to implement this feature request
[ ] :warning: This feature might incur a breaking change
This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.
Simply, provide a way-forward whereby attempting to use the
add*Command
methods inherited fromUserData
do not throw exceptions. Rather, invoking the methods onMultipartUserData
passes the invocation through to a designatedUserData
object.Use Case
CDK construct libraries (like https://github.com/aws/aws-rfdk) allow the customer to provide a
UserData
object into an L3 construct. That L3 construct may use the provided UserData object in the creation of Instances, AutoScaling Groups, etc, but also use methods on the UserData such asaddCommands()
,addS3DownloadCommand()
, etc to set up initialization required by the L3 construct.Having these methods on the
MultipartUserData
throw exceptions makes it awkward at best to integrate the class with these libraries. Without this change toMultipartUserData
these libraries would be required to accept both aUserData
andMultipartUserData
property to supportMultipartUserData
-- commands would be added to theUserData
, but theMultipartUserData
would be used to actually render the Instance/ASG's -- and enforce, somehow, that the givenUserData
is a part in the givenMultipartUserData
. It's all very awkward.Proposed Solution
I have a candidate PR prepped, and will be posting it momentarily.
This is a :rocket: Feature Request