-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(aws-eks) Dummy VPC injected during lookup pass cause dependent constructs to eventually fail #19425
Comments
As a side note, the same behavior applies to some_role_arn: str = StringParameter.value_from_lookup(
scope=self, parameter_name="/some/role/arn"
)
# fails as, "some_role_arn" will be set to "dummy-value-for-/some/role/arn" during the first pass
# which is NOT a valid ARN
Role.from_role_arn(
scope=self,
id="SomeRoleARN",
role_arn=some_role_arn,
) This needs to be explicitly handled into the code degrading user experience, code maintainability, readability etc etc some_role_arn: str = StringParameter.value_from_lookup(
scope=self, parameter_name="/some/role/arn"
)
if some_role_arn.startswith("dummy-value-for-"):
some_role_arn = "arn:aws:iam::000000000000:role/dummy-role-arn"
Role.from_role_arn(
scope=self,
id="SomeRoleARN",
role_arn=some_role_arn,
) |
Duplicate of #8699 |
|
What is the problem?
This is a follow-up for issue: #10341
Whenever VPC lookup is in the picture the CDK appears to be doing two passes on the code:
vpc-12345
with subnetss-12345
,s-67890
,p-12345
, andp-67890
) that, whenever not compatible with the subnet selection scheme, cause dependent constructs to eventually failcdk.context.json
has been properly materialized and the target selection logic can be successfully applied as the code will be finally dealing with real-life valuesReproduction Steps
The code below fails to
synth
as the dummy values from the first pass will not satisfy theSubnetSelection
scheme.As opposed to the example listed here I'm using a custom
subnet_group_name_tag
andSubnetSelection
but this is just an implementation detail.Workaround
As mentioned here you need to figure out whether you are on the first or the second pass and handle both cases gracefully with regards to the Constructs consuming the subnet selection.
Alternatively, temporarily commenting out the failing code to generate the
cdk.context.json
should also be viable as this is some kind of "chicken and egg problem". It does NOT work for me since I'm packaging the CDK code as a re-usable asset to be run against a complex and dynamic, multi-account architecture, with no prior knowledge about which account it will be deployed against.What did you expect to happen?
Ideally, lookups would occur as a preliminary "decoupled" stage and there would be no need to temporarily inject dummy objects into the picture.
What actually happened?
A dummy VPC object (with invalid CIDR 1.2.3.4/5 etc etc) is temporarily injected during the first pass waiting for
cdk.context.json
to be materialized.CDK CLI Version
2.8.0 (build 8a5eb49)
Framework Version
aws-cdk-lib==2.8.0
Node.js Version
v16.10.0
OS
MacOS 11.6.3
Language
Python
Language Version
Python(3.9.10)
Other information
No response
The text was updated successfully, but these errors were encountered: