fix(appconfig): apply retain removal policy only to hosted configurat… #26829

chenjane-dev · 2023-08-21T16:16:17Z

…ion version update replace

Addressing #26804 to add retain removal policy only on update replace and not on delete.

I'm using the new L2 constructs, sample code below.
Deploying works just fine.
However, on destroy i get the following error:
11:24:04 AM | DELETE_FAILED | AWS::AppConfig::ConfigurationProfile | rootappconfigOrder...ionProfile9C631413 Cannot delete configuration profile bvdne2p because there are still hosted configuration versions existing under it. (Service: AmazonAppConfig; Status Code: 400; Error Code: BadRequestException; Request ID: d1d449de-9138-4a5e-8461-05f925d07bae; Proxy: null)

This fixes the problem, since before we are using applyRemovalPolicy(RemovalPolicy.RETAIN) on the hosted config version, which sets the removal to retain on both delete and update. We wanted to set this to retain so hosted config versions are not deleted if updated. However, if the stack is being deleted, then we don't want to retain the hosted config version and that is why we are fixing it to only set the removal policy to retain on an update replace.

In addition, I see reference in the original thread to "I have a CloudFormation template that destroys fine". The current change does not seem to move us closer to destroying properly?

This is in reference to the user using our L1 constructs, where the hosted config version deletes correctly.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

aws-cdk-automation · 2023-08-21T16:43:06Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
Commit ID: 01ca5f7
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

The current logic counts the number of changes in any parent stacks. It doesn't count nested stacks correctly, and doesn't count parent stacks correctly. With this change: <img width="1047" alt="Screenshot 2023-08-18 at 9 43 49 AM" src="https://github.com/aws/aws-cdk/assets/66279577/b417baa7-58d9-454a-a735-4bd406f1c126"> Without this change: <img width="1047" alt="Screenshot 2023-08-18 at 9 51 55 AM" src="https://github.com/aws/aws-cdk/assets/66279577/85e87e72-25ec-47af-96af-f47f7c43a4f2"> Closes aws#26818. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…6155) Changing Logical IDs for EfsMountTarget While using the forEach, index will be added as a suffix to logical id of EfsMountTarget this is causing an error when the subnets array in the props has changed. Closes aws#25099 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…fined" (aws#26800) The repository name is embedded in the `description` of `CustomResourceProvider` for the ECR AutoDeleteImages, but the repository name becomes to `undefined` because the `CustomResourceProvider` is created before the repository name is set. ```ts private enableAutoDeleteImages() { const firstTime = Stack.of(this).node.tryFindChild(`${AUTO_DELETE_IMAGES_RESOURCE_TYPE}CustomResourceProvider`) === undefined; const provider = CustomResourceProvider.getOrCreateProvider(this, AUTO_DELETE_IMAGES_RESOURCE_TYPE, { codeDirectory: path.join(__dirname, '..', '..', 'custom-resource-handlers', 'dist', 'aws-ecr', 'auto-delete-images-handler'), useCfnResponseWrapper: false, runtime: CustomResourceProviderRuntime.NODEJS_18_X, description: `Lambda function for auto-deleting images in ${this.repositoryName} repository.`, }); ``` So I moved the `enableAutoDeleteImages` calls after following codes that set `repositoryName` in the `Repository` constructor. ```ts this.repositoryName = this.getResourceNameAttribute(resource.ref); ``` ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

rix0rrr

Please make sure that your PR body describes the problem the PR is solving, and the design approach and alternatives considered. Explain why the PR solves the problem. A link to an issue is helpful, but does not replace an explanation of your thought process (See Contributing Guide, Pull Requests)

In addition, I see reference in the original thread to "I have a CloudFormation template that destroys fine". The current change does not seem to move us closer to destroying properly?

AWS Service Spec packages to latest versions.

Amazon ECS [supports](https://aws.amazon.com/it/about-aws/whats-new/2022/12/amazon-ecs-supports-container-port-ranges-port-mapping/) container port ranges for port mapping since quite a bit, however the `ContainerDefinition` L2 construct does not expose a way to set them. Right now, the only viable solution I found to use the feature is using Escape Hatches. Within this PR, the `containerPortRange` property is added to the `PortMapping` object and mapped back to the underlying L1 construct. The current implementation contains a breaking change: since setting both a port range and a single fixed port doesn't make sense, I had to mark optional all the properties of `PortMapping`, hence the `containerPort` property changed its type from `non-nullable` to `nullable`. The downside of the proposed solution is that now all the properties are optional and the compiler doesn't complain if an empty object is passed as port mapping. I added some runtime checks to ensure that a valid object is created, but I didn't find a better way to do it at compile time that is also compatible with the transformation done by `jsii`. Closes aws#23509. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…'s description (aws#26149) When creating an instance of a `RestApi` construct, by default it has a `Deployment` attached to it. The description of the `Deployment` can be configured with an option given to the `RestApi`, like so: ```tsx const api = new RestApi(this, 'Api', { restApiName: 'MyApi', deployOptions: { description: 'Deployment description' } }); ``` However, looking at the [source code](https://github.com/aws/aws-cdk/blob/72eb1e957afb9d1573445999eddd38b5c345fa7a/packages/aws-cdk-lib/aws-apigateway/lib/restapi.ts#L592C25-L592C25), we see that instead of using the `props.deployOptions.description`, it uses `props.description`. Fixes aws#26148 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…untu7 (aws#26817) Node 16 is approaching end-of-life (2023-09-11). This changes the default image version to `aws/codebuild/standard:7.0` which uses Node 18. Closes aws#26810. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

The resource logical ID validation regex (`VALID_LOGICALID_REGEX`) is updated to be consistent with the [CloudFormation documentation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resources-section-structure.html) which says that logical IDs are alphanumeric. Closes aws#26075. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

The interface EbsOptions for the opensearchservices CDK construct is missing a provisioned throughput option for eg gp3 instance types. iops is there, but not throughput Closes aws#26137. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Specifying the `securityGroups` property requires a `vpc`. This fix adds validation for the case when a `vpc` is not specified, but `securityGroups` is. It also adds validation for the case when both `securityGroups` and `allowAllOutbound` are specified (`allowAllOutbound` should be configured in the SGs). **Question for the reviewers** How should we handle the case of an empty list in `securityGroups`? (eg `securityGroups: []`) Closes aws#26508. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Removes the map of regions -> available lambda nodejs runtime versions that previously was used for all custom resources vended in the aws-cdk. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…#26580) Synthetics [used](https://aws.amazon.com/about-aws/whats-new/2022/05/amazon-cloudwatch-synthetics-support-canary-resources-deletion/) to have a property `deleteLambdaResourceOnCanaryDeletion` that has since been deprecated and erased from cloudformation docs. Although this property still works today synthetics makes no promises that this is supported in the future. Here in CDK land, this PR serves as a replacement to the `deleteLambdaResourceOnCanaryDeletion` property (called `enableAutoDeleteLambdas` on the L2 Canary) by implementing a custom resource similar to what we have in S3 and ECR. **This PR deprecates `enableAutoDeleteLambdas` in favor of `cleanup: cleanup.LAMBDA`, an enum that achieves the same thing but via custom resource** Closes aws#18448 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This GitHub Action updates a CONTRIBUTORS file with the top contributors from the project, pulling contents from the GitHub API. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…aws#26813) Pre 2.89.0 we could import a secret from a complete secret arn in one stack and reference this secret from another stack in a different region to include it in a policy/role through grantRead on the secret construct. Since 2.89.0 the arn in the policy it treats the compledSecretArn as a partial arn adding -?????? which makes the policy invalid and not allowing access to the secret as intended. This PR fixes that by overriding arnForPolicies for imported secrets to either return provided complete arn or partial arn with suffix. Fixes aws#26811. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

A few weeks ago I added the --ssh flag to the constructs for building a cdk with that arg; However, I missed actually passing that arg to the docker.build in the cdk-assets container-images. This adds that arg where it should be. Closes 12062. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

rix0rrr · 2023-08-23T11:39:03Z

Why do we have RETAIN on these resources in the first place? Do we know?

Are we sure using a different policy for stack updates and stack deletes is the right solution? It feels to me that either we need to retain them in both cases, for some reason, or we need to retain them in neither case.

Your current change will fix the following sequence of events:

Deploy
Destroy

But I'm pretty sure it will fail in the following sequence of events:

Deploy
Update causing a replacement
Destroy

Here's my motivation for questioning this solution: if we had the following sequence of events:

1. Deploy using HostedConfiguration and HostedConfigurationVersion

The service state will look like this:

                                                                                           
                 State of service                     State tracked by CloudFormation      
                                                                                           
                                                                                           
┌────────────────────────┐                               ┌────────────────────────────────┐
│                        │                               │                                │
│  HostedConfiguration   │◀──────────────────────────────│      HostedConfiguration       │
│                        │                               │                                │
└────────────────────────┘                               └────────────────────────────────┘
             │                                                                             
             │    ┌─────────────────┐                    ┌────────────────────────────────┐
             │    │                 │                    │                                │
             └────│   HCVersion 1   │◀───────────────────│   HostedConfigurationVersion   │
                  │                 │                    │                                │
                  └─────────────────┘                    └────────────────────────────────┘

2. Update HostedConfigurationVersion causing a replacement

The old Version will be RETAINed, because its UpdateReplacePolicy will be set to RETAIN.

The service will end up 2 versions, of which CloudFormation will be tracking the latest.

                                                                                           
                 State of service                     State tracked by CloudFormation      
                                                                                           
                                                                                           
┌────────────────────────┐                               ┌────────────────────────────────┐
│                        │                               │                                │
│  HostedConfiguration   │◀──────────────────────────────│      HostedConfiguration       │
│                        │                               │                                │
└────────────────────────┘                               └────────────────────────────────┘
             │                                                                             
             │    ┌─────────────────┐                                                      
             │    │                 │                                                      
             ├────│   HCVersion 1   │                                                      
             │    │                 │                                                      
             │    └─────────────────┘                                                      
             │                                                                             
             │                                                                             
             │    ┌─────────────────┐                    ┌────────────────────────────────┐
             │    │                 │                    │                                │
             └────│   HCVersion 2   │◀───────────────────│   HostedConfigurationVersion   │
                  │                 │                    │                                │
                  └─────────────────┘                    └────────────────────────────────┘

3. Delete stack

CloudFormation will delete the resources it knows about, in reverse dependency order.

Because CloudFormation doesn't know about HCVersion 1 anymore, it will not delete it, and so deleting the HostedConfiguration will fail.

                                                                                           
                 State of service                     State tracked by CloudFormation      
                                                                                           
                                                                                           
┌────────────────────────┐                               ┌────────────────────────────────┐
│                        │                               │                                │
│  HostedConfiguration   │◀───2. DELETE !!! FAIL !!!─────│      HostedConfiguration       │
│                        │                               │                                │
└────────────────────────┘                               └────────────────────────────────┘
             │                                                                             
             │    ┌─────────────────┐                                                      
             │    │                 │                                                      
             ├────│   HCVersion 1   │                                                      
             │    │                 │                                                      
             │    └─────────────────┘                                                      
             │                                                                             
             │                                                                             
             │    ┌─────────────────┐                    ┌────────────────────────────────┐
             │    │                 │                    │                                │
             └────│   HCVersion 2   │◀───── 1. DELETE ───│   HostedConfigurationVersion   │
                  │                 │                    │                                │
                  └─────────────────┘                    └────────────────────────────────┘

Yaml is incorrect causing the workflow to not run at all. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This PR adds the ability to acknowledge annotation warning messages. The main motivation behind this is to allow people to set the `--strict` mode to fail synthesis on warnings. Currently it is all or nothing, you have to get rid of _all_ warnings to use `--strict`. With this feature users will be able to `acknowledge` warnings saying that they are aware, but it does not apply to them. Since we want all warnings to now have an id this will deprecate the `addWarning` method and adds a new `addWarningV2` method. Since the acknowledgements and warnings are written as metadata, it is possible to enhance this in the future to report on warnings and acknowledgements. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…licy (aws#26836) Adds a `cloudWatchRoleRemovalPolicy` property to `RestApiBaseProps` that allows to specify a custom retention policy for CloudWatchRole and Account. Defaults to `RemovalPolicy.RETAIN`. Closes aws#26827. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This PR adds a possibility to use local bundling and let the final asset be one single file that is uploaded as-is. This can be used for several types of assets, e.g. AppSync functions. In contrast to Lambda, these functions to not expect the asset to be a zip file. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Using helm charts in a private ECR repo is not possible in govcloud regions, as the regex is too narrowly defined. This change will properly match against all current AWS regions. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

chenjane-dev · 2023-08-23T14:11:31Z

Why do we have RETAIN on these resources in the first place? Do we know?

Are we sure using a different policy for stack updates and stack deletes is the right solution? It feels to me that either we need to retain them in both cases, for some reason, or we need to retain them in neither case.

Your current change will fix the following sequence of events:

1. Deploy

2. Destroy

But I'm pretty sure it will fail in the following sequence of events:

1. Deploy

2. Update causing a replacement

3. Destroy

Here's my motivation for questioning this solution: if we had the following sequence of events:

1. Deploy using HostedConfiguration and HostedConfigurationVersion

The service state will look like this:

                                                                                           
                 State of service                     State tracked by CloudFormation      
                                                                                           
                                                                                           
┌────────────────────────┐                               ┌────────────────────────────────┐
│                        │                               │                                │
│  HostedConfiguration   │◀──────────────────────────────│      HostedConfiguration       │
│                        │                               │                                │
└────────────────────────┘                               └────────────────────────────────┘
             │                                                                             
             │    ┌─────────────────┐                    ┌────────────────────────────────┐
             │    │                 │                    │                                │
             └────│   HCVersion 1   │◀───────────────────│   HostedConfigurationVersion   │
                  │                 │                    │                                │
                  └─────────────────┘                    └────────────────────────────────┘

2. Update HostedConfigurationVersion causing a replacement

The old Version will be RETAINed, because its UpdateReplacePolicy will be set to RETAIN.

The service will end up 2 versions, of which CloudFormation will be tracking the latest.

                                                                                           
                 State of service                     State tracked by CloudFormation      
                                                                                           
                                                                                           
┌────────────────────────┐                               ┌────────────────────────────────┐
│                        │                               │                                │
│  HostedConfiguration   │◀──────────────────────────────│      HostedConfiguration       │
│                        │                               │                                │
└────────────────────────┘                               └────────────────────────────────┘
             │                                                                             
             │    ┌─────────────────┐                                                      
             │    │                 │                                                      
             ├────│   HCVersion 1   │                                                      
             │    │                 │                                                      
             │    └─────────────────┘                                                      
             │                                                                             
             │                                                                             
             │    ┌─────────────────┐                    ┌────────────────────────────────┐
             │    │                 │                    │                                │
             └────│   HCVersion 2   │◀───────────────────│   HostedConfigurationVersion   │
                  │                 │                    │                                │
                  └─────────────────┘                    └────────────────────────────────┘

3. Delete stack

CloudFormation will delete the resources it knows about, in reverse dependency order.

Because CloudFormation doesn't know about HCVersion 1 anymore, it will not delete it, and so deleting the HostedConfiguration will fail.

                                                                                           
                 State of service                     State tracked by CloudFormation      
                                                                                           
                                                                                           
┌────────────────────────┐                               ┌────────────────────────────────┐
│                        │                               │                                │
│  HostedConfiguration   │◀───2. DELETE !!! FAIL !!!─────│      HostedConfiguration       │
│                        │                               │                                │
└────────────────────────┘                               └────────────────────────────────┘
             │                                                                             
             │    ┌─────────────────┐                                                      
             │    │                 │                                                      
             ├────│   HCVersion 1   │                                                      
             │    │                 │                                                      
             │    └─────────────────┘                                                      
             │                                                                             
             │                                                                             
             │    ┌─────────────────┐                    ┌────────────────────────────────┐
             │    │                 │                    │                                │
             └────│   HCVersion 2   │◀───── 1. DELETE ───│   HostedConfigurationVersion   │
                  │                 │                    │                                │
                  └─────────────────┘                    └────────────────────────────────┘

The reason this is set to retain currently is because this deals with config versions. When a customer creates a new config version, we want to retain any old, existing versions, in the case that the customer later wants to deploy/access an old version. We have had customers ask for this when using our L1 constructs.

Having them as separate removal policies makes sense because in the case of removal, the customer is deleting the entire stack and hence all AppConfig resources in the stack. If the config profile is getting deleted, then it doesn't make sense for the hosted config version to be retained since it only exists under the scope of a config profile. Also, since we have nested resources, keeping the hosted config version set to retain on delete will cause failures when trying to delete the application and config profile in the stack (as mentioned in the issue linked above), which does not make for the best customer experience, as they are trying to delete the entire stack (including all AppConfig resources). Only on update does the retain policy make sense for the user because of the reasoning in the first paragraph.

…26910) If the same asset is used in 2 stacks that use different synthesizer configurations for publishing (for example, by using a different prefix) the asset will only be uploaded once instead of twice. We used to make the assumption that it was okay to use the destination ID as token of uniqueness. This is true inside a single manifest, but does not hold when there is more than stack that each have a manifest: both may have the destination ID `current_account:current_region`, but have different parameters for each destination. Instead, we calculate a content hash over the destination definition itself. That way, if the definitions are different we will create different nodes for each of them. Fixes aws#25927. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This PR is for the implementation of the `GlobalTable` L2. Please reference the following RFC: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0510-dynamodb-global-table.md Closes aws#16118 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…5.2 (aws#26923) Also removes the following warning: ``` DeprecationWarning: 'originalKeywordKind' has been deprecated since v5.0.0 and will no longer be usable after v5.2.0. Use 'identifierToKeywordKind(identifier)' instead. ``` ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Checks off some items from aws#26757 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Add support for [AppSync Merged API](https://aws.amazon.com/blogs/mobile/introducing-merged-apis-on-aws-appsync/) feature. At the moment, a GraphQL schema can be passed using the `schema` property. I deprecated this property because it is not used for merged APIs. Depecreated syntax: ```ts const api = new appsync.GraphqlApi(this, 'Api', { name: 'demo', schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema.graphql')), }); ``` Instead, I introduced a new property `apiSource` that can be used to create a AppSync GraphQL API or Merged API. GraphQL API: ```ts const api = new appsync.GraphqlApi(this, 'Api', { name: 'demo', apiSource: appsync.ApiSource.fromSchema(appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema.graphql'))), // short version apiSource: appsync.ApiSource.fromFile(path.join(__dirname, 'schema.graphql')), }); ``` Merged API: ```ts const api = new appsync.GraphqlApi(this, 'Api', { name: 'demo', apiSource: appsync.ApiSource.fromSourceApis({ sourceApis: [ { sourceApi: firstApi, mergeType: appsync.MergeType.MANUAL_MERGE, }, { sourceApi: secondApi, mergeType: appsync.MergeType.AUTO_MERGE, }, ], }), }); ``` Closes aws#25960. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ws#26921) Upgrades a few runtime versions from `NODEJS_14_X` (which is EOL and will enter Deprecation Phase 1 on Nov 27, 2023) to `NODEJS_16_X`. Also updates all the tests. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

They execute correctly locally and in a PR build, but not in the Pipeline because the `framework-integ` package gets an `-alpha.999` suffix (whereas the actual constructs get an `-rc.0` suffix). The test used to read the expected version from its own `package.json`. It will now read the expected version from `aws-cdk-lib`'s `package.json`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Ran npm-check-updates and yarn upgrade to keep the `yarn.lock` file up-to-date.

Its deprecation is causing problems for `cdk-nag`, which has a use case for unsuppressible warnings. Undeprecate for now until we come up with a better all-round solution. Relates to aws#26914. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

I felt it best to keep most of the details in the linked documentation, but I believe this provides a good overview. Closes aws#21103. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ld counts (aws#26949) `HealthyThresholdCount` and `UnhealthyThresholdCount` do not need to be the same. In fact, the [docs](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html#health-check-settings) have their default values as 5 and 2. Closes aws#26941. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…s-cdk/aws-lambda-python-alpha/test/lambda-handler-poetry (aws#26956) Bumps [certifi](https://github.com/certifi/python-certifi) from 2023.5.7 to 2023.7.22. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/certifi/python-certifi/commit/8fb96ed81f71e7097ed11bc4d9b19afd7ea5c909"><code>8fb96ed</code></a> 2023.07.22</li> <li><a href="https://github.com/certifi/python-certifi/commit/afe77220e0eaa722593fc5d294213ff5275d1b40"><code>afe7722</code></a> Bump actions/setup-python from 4.6.1 to 4.7.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/230">#230</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/2038739ad56abec7aaddfa90ad2ce6b3ed7f5c7b"><code>2038739</code></a> Bump dessant/lock-threads from 3.0.0 to 4.0.1 (<a href="https://redirect.github.com/certifi/python-certifi/issues/229">#229</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/44df761f4c09d19f32b3cc09208a739043a5e25b"><code>44df761</code></a> Hash pin Actions and enable dependabot (<a href="https://redirect.github.com/certifi/python-certifi/issues/228">#228</a>)</li> <li>See full diff in <a href="https://github.com/certifi/python-certifi/compare/2023.05.07...2023.07.22">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=certifi&package-manager=pip&previous-version=2023.5.7&new-version=2023.7.22)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/aws/aws-cdk/network/alerts). </details>

…ws#26917) Currently, the region parameter in `AwsCustomResource` only controls where the action is performed. If a role needs to be assumed, the `assumeRole` call is made from the region the stack is deployed into. This presents a problem if the stack is deployed into an opt-in region, and the role being assumed lives in a separate stack in an account without the opt-in region enabled. This change makes the `assumeRole` call and the sdk call performed in the same region. Therefore, to solve the above problem, pass any region that is enabled for the account that owns the role to be assumed. Closes aws#26562. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action

Reverts aws#26563

…aws#26962) Closes aws#26952. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This adds the ability to use the latest two NodeJS runtimes in your Synthetics construct. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…nnot be set at once (aws#26971) This PR adds comments that both defaultInterval and start for dashboard cannot be set at once. The following is a validation code for them. https://github.com/go-to-k/aws-cdk/blob/05d1c524e356f0e3cbd4799c6f7d233a44301954/packages/aws-cdk-lib/aws-cloudwatch/lib/dashboard.ts#L135-L137 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Signed-off-by: Vinayak Kukreja <[email protected]>

See [CHANGELOG](https://github.com/aws/aws-cdk/blob/bump/2.94.0/CHANGELOG.md)

See [CHANGELOG](https://github.com/aws/aws-cdk/blob/merge-back/2.94.0/CHANGELOG.md)

AWS Service Spec packages to latest versions.

I found some grammatical errors while debugging an issue. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…#26930) When a DeliveryStream is created without `sourceStream` or `encryptionKey`, an extra role is being created that is unused. This PR removes creation of that role. I also learned that the role created for `encryptionKey` is used "indirectly" for a grant put on the KMS key...interesting. Closes aws#26927. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

The upcoming v6 of the [VSCode jest plugin](https://github.com/jest-community/vscode-jest#virtualfolders) allows us to configure our monorepo packages as virtual folders. This makes the built-in Test Explorer work out of the box. <img width="466" alt="image" src="https://github.com/aws/aws-cdk/assets/379814/b98b3736-4713-49d7-bec6-816f14816e73"> Using the workspace is entirely optional. It can also serve as an example configurations. But it does give a space to add recommended/opinionated VSCode settings without compromising contributor's ability to change `.vscode/settings.json`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…16 (aws#26980) Updates the `CrossAccountZoneDelegationRecord` construct to use sdk v3 / node 18. This is identical to changes in aws#26212, except for hardcoding a region into the `assumeRole` sdk call. This may not be the ideal solution, but should not break specific configurations. That specific configuration, as aws#26593 pointed out, was that the original update was a breaking change if the construct was deployed into an opt-in region, and the parent zone did not have that opt-in region enabled. This PR removes the semi-hidden `@aws-cdk/aws-route53:useRegionalStsEndpoint` feature flag, as it was based on a confusion on why things used to work. We now pick the correct endpoint manually. Closes aws#26976. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

keenangraham · 2023-09-19T22:11:24Z

we want to retain any old, existing versions, in the case that the customer later wants to deploy/access an old version

I see how that makes sense.

Do you understand my concern of how RETAIN-on-replace, DELETE-on-delete is going to lead to the exact same problem you're trying to fix though, just one step later?

CloudFormation can only keep track of as many Hosted Config Versions as there are AWS::AppConfig::HostedConfigVersion resources in the template. In the current design there is only 1 of those, so CloudFormation can only keep track of 1 HCV in your service. It will therefore only call DeleteHostedConfigVersion at most once come delete time.

If you have triggered any replacements in the mean time, those other HCVs will have "leaked", and will cause an error when DeletedHostedConfig is called.

To make the DeleteHostedConfig call succeed, one of the following must be true:

DeleteHostedConfig must automatically delete all Versions (I'm pretty sure this is not true, otherwise we wouldn't have seen the reported error).

HostedConfigVersion replacements can and will never happen. That means there will always be at most one Version, and that's the one that will be deleted (I'm not sure whether or not this is true, I'm guessing it's not).

We must have as many AWS::AppConfig::HostedConfigVersion resources in the CloudFormation template as there are versions in the HostedConfig. That's the only way to make CloudFormation clean them up correctly. This could be possible, but may need a redesign of the construct, and might become awkward to use (I haven't looked at the API or the usage patterns yet).

We need some out-of-band way to clean up all the HostedConfigVersions come delete time. Probably a custom resource, the same way we clean out an S3 bucket before calling DeleteBucket.

Ah, yes I see what you're saying. I will get back to you on this.

Did this get resolved? The PR says merged but it doesn't look like any AppConfig code added.

Seems like need a way to clean out all HostedConfigVersions when deleting a stack (like S3 bucket and files).

A little confused how the underlying CloudFormation is supposed to work here, since it only tracks and tries to delete the version it deployed, even though the whole point of AppConfig is to make quick deployments in the console by flipping a toggle (without need for CF deployment)? But if you make any changes in the console, the CF stack will fail to delete because of untracked versions.

github-actions bot added the beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK label Aug 21, 2023

aws-cdk-automation requested a review from a team August 21, 2023 16:16

github-actions bot added the p2 label Aug 21, 2023

aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Aug 21, 2023

comcalvi and others added 4 commits August 21, 2023 17:38

rix0rrr requested changes Aug 22, 2023

View reviewed changes

aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Aug 22, 2023

aws-cdk-automation and others added 12 commits August 22, 2023 12:09

feat: update AWS Service Spec (aws#26825)

4133729

AWS Service Spec packages to latest versions.

mrgrain and others added 5 commits August 23, 2023 12:00

chore: fix incorrect yaml in update-contributors.yml (aws#26850)

dc8f313

Yaml is incorrect causing the workflow to not run at all. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

rix0rrr and others added 28 commits August 29, 2023 13:59

chore(region-info): ap-southeast-4 region (aws#26919)

9ccab73

Checks off some items from aws#26757 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

chore: npm-check-updates && yarn upgrade (aws#26938)

57bcd9a

Ran npm-check-updates and yarn upgrade to keep the `yarn.lock` file up-to-date.

chore: update Contributors File (aws#26961)

040ac48

Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action

revert: "feat(dynamodb): global table L2" (aws#26960)

d6b71ad

Reverts aws#26563

chore(integ-tests-alpha): add redshift serverless to sdk api metadata (…

078e26a

…aws#26962) Closes aws#26952. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

feat(synthetics-alpha): add latest two NodeJS runtimes (aws#26967)

0a0b37c

This adds the ability to use the latest two NodeJS runtimes in your Synthetics construct. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

chore(release): 2.94.0

f0f9ce6

chore: update changelog

4ef13ce

Signed-off-by: Vinayak Kukreja <[email protected]>

chore(release): 2.94.0 (aws#26975)

987c329

See [CHANGELOG](https://github.com/aws/aws-cdk/blob/bump/2.94.0/CHANGELOG.md)

chore(merge-back): 2.94.0 (aws#26981)

408f1f6

See [CHANGELOG](https://github.com/aws/aws-cdk/blob/merge-back/2.94.0/CHANGELOG.md)

feat: update AWS Service Spec (aws#26999)

a0458b7

AWS Service Spec packages to latest versions.

docs(ssm): fix grammatical errors for StringParameter (aws#27004)

e628e6e

I found some grammatical errors while debugging an issue. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

mergify bot merged commit d69c51a into aws:main Sep 5, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(appconfig): apply retain removal policy only to hosted configurat… #26829

fix(appconfig): apply retain removal policy only to hosted configurat… #26829

chenjane-dev commented Aug 21, 2023 •

edited

Loading

aws-cdk-automation commented Aug 21, 2023

rix0rrr left a comment

rix0rrr commented Aug 23, 2023 •

edited

Loading

chenjane-dev commented Aug 23, 2023

1. Deploy using HostedConfiguration and HostedConfigurationVersion

2. Update HostedConfigurationVersion causing a replacement

3. Delete stack

keenangraham commented Sep 19, 2023

fix(appconfig): apply retain removal policy only to hosted configurat… #26829

fix(appconfig): apply retain removal policy only to hosted configurat… #26829

Conversation

chenjane-dev commented Aug 21, 2023 • edited Loading

aws-cdk-automation commented Aug 21, 2023

AWS CodeBuild CI Report

rix0rrr left a comment

Choose a reason for hiding this comment

rix0rrr commented Aug 23, 2023 • edited Loading

1. Deploy using HostedConfiguration and HostedConfigurationVersion

2. Update HostedConfigurationVersion causing a replacement

3. Delete stack

chenjane-dev commented Aug 23, 2023

1. Deploy using HostedConfiguration and HostedConfigurationVersion

2. Update HostedConfigurationVersion causing a replacement

3. Delete stack

keenangraham commented Sep 19, 2023

chenjane-dev commented Aug 21, 2023 •

edited

Loading

rix0rrr commented Aug 23, 2023 •

edited

Loading