feat(cli): improved interactions for NestedStack and NestedStack resources #7805

andrestone · 2020-05-05T16:18:50Z

Commit Message

feat(cli): improved interactions for NestedStack and NestedStack resources

NestedStack and NestedStack resources outputs for various workflows

End Commit Message

This is a WIP

Todo

Discussions

Immutable nature of Assets and NestedStacks traceability

Since NestedStacks aren't regular, deployable stacks, the toolkit can't make use of the standard selectStacks method from the assembly, as NestedStacks are synthesised as separate template units, to be later consumed as assets. These assets are immutable, which means that there's no traceability for changes in those files per se.

Therefore, in order to support CLI routines like diff and printSecurityDiff, some sort of extrinsic mechanism should be established to bind current NestedStack templates to the ones product of a synth.

This could be done by using the the LogicalId of the NestedStack resource as an identifier (and by coding the "resource -> template" relation inference, see item 2 below).

In addition to the referred method (which is backwards compatible), this PR adds the Stack uniqueId as a Metadata to the NestedStack CFN template, for a stronger binding between the nested stack and the parent stack resource as well as better traceability. It was done by adding this code to the core.NestedStack constructor:

    Stack.of(this).templateOptions.metadata = {
      [cxapi.NESTEDSTACK_UNIQUEID_KEY]: this.node.uniqueId, // or maybe this.node.uniqueId ?
    };

cxapi.NESTEDSTACK_UNIQUEID_KEY is currently cxapi.PATH_METADATA_KEY in the code. Waiting for some sort of approval before rerunning integration tests and rewritting expected.json files.

Still, the feature would be backwards compatible since the methods first try the Metadata field and fall back to the parent LogicalId if not found.

^^^ This modifies the source hash of the NestedStacks, that's why so many changes to test files

NestedStacks verbosity on `cdk synth`

RFC: Should these always display NestedStack content or optionally via cli args? Currently always showing.

^^^ This impacts expected.json for many integration tests.

NestedStacks and the done / total info on `cdk deploy`

1/3 <--- | 4:45:53 PM | CREATE_IN_PROGRESS | AWS::SNS::Topic | MyWrapped/MyTopic (MyTopicB31DCDED)

RFC: Should the total resources and total resources done be updated based on the discovered NestedStacks?

Details

The goal is to improve the CLI interactions by displaying relevant NestedStack's resource information in various workflows:

`cdk deploy` and `cdk destroy` CloudFormation status updates (#7699, #5974, #6402)

CDK displays status messages based on calls to the describeStackEvents method of the CloudFormation API. The method doesn't return relevant information about the resources that belong to a NestedStack, acting as if it was a regular resource.

This PR implements recursive calls to the describeStackEvents API for every NestedStack.

Currently:

...
 0/3 | 5:12:04 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | MyWrapped.NestedStack/MyWrapped.NestedStackResource (MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250)
 0/3 | 5:12:05 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | MyWrapped.NestedStack/MyWrapped.NestedStackResource (MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250) Resource creation Initiated
 2/3 | 5:12:27 PM | CREATE_COMPLETE      | AWS::CloudFormation::Stack | MyWrapped.NestedStack/MyWrapped.NestedStackResource (MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250)
...

PR:

...
 0/3 | 4:45:48 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | MyWrapped.NestedStack/MyWrapped.NestedStackResource (MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250)
 0/3 | 4:45:49 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | MyApp-MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250-W45I2Q2KUU2Y User Initiated
 0/3 | 4:45:49 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | MyWrapped.NestedStack/MyWrapped.NestedStackResource (MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250) Resource creation Initiated
 1/3 | 4:45:53 PM | CREATE_IN_PROGRESS   | AWS::SNS::Topic            | MyWrapped/MyTopic (MyTopicB31DCDED)
 1/3 | 4:45:53 PM | CREATE_IN_PROGRESS   | AWS::SQS::Queue            | MyWrapped/MyQueue (MyQueueE5766AC5)
 1/3 | 4:45:53 PM | CREATE_IN_PROGRESS   | AWS::SNS::Topic            | MyWrapped/MyTopic (MyTopicB31DCDED) Resource creation Initiated
 1/3 | 4:45:53 PM | CREATE_IN_PROGRESS   | AWS::SQS::Queue            | MyWrapped/MyQueue (MyQueueE5766AC5) Resource creation Initiated
 1/3 | 4:45:55 PM | CREATE_COMPLETE      | AWS::SQS::Queue            | MyWrapped/MyQueue (MyQueueE5766AC5)
 1/3 | 4:46:04 PM | CREATE_COMPLETE      | AWS::SNS::Topic            | MyWrapped/MyTopic (MyTopicB31DCDED)
 1/3 | 4:46:06 PM | CREATE_IN_PROGRESS   | AWS::SQS::QueuePolicy      | MyWrapped/MyQueue/Policy (MyQueuePolicy0D986D96)
 1/3 | 4:46:06 PM | CREATE_IN_PROGRESS   | AWS::SNS::Subscription     | MyWrapped/MyQueue/MyAppMyWrappedMyTopic6E6A168B (MyQueueMyAppMyWrappedMyTopic6E6A168B140E116C)
 1/3 | 4:46:07 PM | CREATE_IN_PROGRESS   | AWS::SQS::QueuePolicy      | MyWrapped/MyQueue/Policy (MyQueuePolicy0D986D96) Resource creation Initiated
 1/3 | 4:46:07 PM | CREATE_COMPLETE      | AWS::SQS::QueuePolicy      | MyWrapped/MyQueue/Policy (MyQueuePolicy0D986D96)
 1/3 | 4:46:07 PM | CREATE_IN_PROGRESS   | AWS::SNS::Subscription     | MyWrapped/MyQueue/MyAppMyWrappedMyTopic6E6A168B (MyQueueMyAppMyWrappedMyTopic6E6A168B140E116C) Resource creation Initiated
 1/3 | 4:46:07 PM | CREATE_COMPLETE      | AWS::SNS::Subscription     | MyWrapped/MyQueue/MyAppMyWrappedMyTopic6E6A168B (MyQueueMyAppMyWrappedMyTopic6E6A168B140E116C)
 1/3 | 4:46:09 PM | CREATE_COMPLETE      | AWS::CloudFormation::Stack | MyApp-MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250-W45I2Q2KUU2Y
 2/3 | 4:46:11 PM | CREATE_COMPLETE      | AWS::CloudFormation::Stack | MyWrapped.NestedStack/MyWrapped.NestedStackResource (MyWrappedNestedStackMyWrappedNestedStackResourceA4ED5250)
 3/3 | 4:46:13 PM | CREATE_COMPLETE      | AWS::CloudFormation::Stack | MyApp
...

`cdk deploy` security-impacting changes (#4490)

RFC: Prompt confirmation for each nested stack or just dump all securityDiffs and ask once?

Currently: no warning

PR:

NestedStacks of the Stack MyApp
IAM Statement Changes
┌───┬───────────────────────────┬────────┬─────────────────┬───────────────────────────┬───────────────────────────────────────────────────────────┐
│   │ Resource                  │ Effect │ Action          │ Principal                 │ Condition                                                 │
├───┼───────────────────────────┼────────┼─────────────────┼───────────────────────────┼───────────────────────────────────────────────────────────┤
│ + │ ${InnerQueueD31D29D2.Arn} │ Allow  │ sqs:SendMessage │ Service:sns.amazonaws.com │ "ArnEquals": {                                            │
│   │                           │        │                 │                           │   "aws:SourceArn": "${InnerTopicD9FDD3A3}"                │
│   │                           │        │                 │                           │ }                                                         │
└───┴───────────────────────────┴────────┴─────────────────┴───────────────────────────┴───────────────────────────────────────────────────────────┘
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)

`cdk diff` (#5722)

Currently:

...
Resources
[+] AWS::CloudFormation::Stack MyFirstInnerThing.NestedStack/MyFirstInnerThing.NestedStackResource MyFirstInnerThingNestedStackMyFirstInnerThingNestedStackResourceA084A5A9

PR:

Stack MyApp
...
Resources
[+] AWS::CloudFormation::Stack MyFirstInnerThing.NestedStack/MyFirstInnerThing.NestedStackResource MyFirstInnerThingNestedStackMyFirstInnerThingNestedStackResourceA084A5A9

NestedStacks of the Stack MyApp
IAM Statement Changes
┌───┬───────────────────────────┬────────┬─────────────────┬───────────────────────────┬───────────────────────────────────────────────────────────┐
│   │ Resource                  │ Effect │ Action          │ Principal                 │ Condition                                                 │
├───┼───────────────────────────┼────────┼─────────────────┼───────────────────────────┼───────────────────────────────────────────────────────────┤
│ + │ ${InnerQueueD31D29D2.Arn} │ Allow  │ sqs:SendMessage │ Service:sns.amazonaws.com │ "ArnEquals": {                                            │
│   │                           │        │                 │                           │   "aws:SourceArn": "${InnerTopicD9FDD3A3}"                │
│   │                           │        │                 │                           │ }                                                         │
└───┴───────────────────────────┴────────┴─────────────────┴───────────────────────────┴───────────────────────────────────────────────────────────┘
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)

...
Resources
[+] AWS::SQS::Queue InnerQueueD31D29D2
[+] AWS::SQS::QueuePolicy InnerQueuePolicyB71D5427
[+] AWS::SNS::Subscription InnerQueueMyAppMyFirstInnerThingInnerTopic3484B86136E2F8DA
[+] AWS::SNS::Topic InnerTopicD9FDD3A3
[+] AWS::CloudFormation::Stack MyInnerBucketNestedStackMyInnerBucketNestedStackResource0F865A6B

...

Resources
[+] AWS::S3::Bucket InnerestNestedBucketB283FE8E
[+] AWS::S3::Bucket AnotherInerestNestedBuckerCE3C1CD9

`cdk synth`

Currently: synth only prints the main stack.

PR:

Stack:
  Resources:
    MyFirstInnerThingNestedStackMyFirstInnerThingNestedStackResourceA084A5A9:
...
NestedStacks:
  MyApp:
    - MyFirstInnerThingNestedStackMyFirstInnerThingNestedStackResourceA084A5A9:
        Template:
          Metadata:
            aws:cdk:path: MyAppMyFirstInnerThingA33CE227
          Resources:
            InnerQueueD31D29D2:
              Type: AWS::SQS::Queue
              Properties:
                VisibilityTimeout: 300
              Metadata:
                aws:cdk:path: MyApp/MyFirstInnerThing/InnerQueue/Resource
...

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

aws-cdk-automation · 2020-05-05T16:43:31Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 6b65224
Result: FAILED
Build Logs (available for 30 days)

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

andrestone · 2020-05-05T17:45:01Z

There seems to be no unit tests for StackActivityMonitor. Wrote an integration test that checks that the inner resource is having its messages displayed.

aws-cdk-automation · 2020-05-05T18:12:51Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 8356bf7
Result: SUCCEEDED
Build Logs (available for 30 days)

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

aws-cdk-automation · 2020-05-05T18:22:24Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: a3bd47e
Result: SUCCEEDED
Build Logs (available for 30 days)

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

eladb

I think it's desirable to deeply recurse to all nested stacks and not just children of the top-level stack.

packages/aws-cdk/test/integ/cli/test-cdk-nested-stack-status.sh

packages/aws-cdk/lib/api/util/cloudformation/stack-activity-monitor.ts

Pull request has been modified.

aws-cdk-automation · 2020-05-06T09:11:44Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: eaf88fe
Result: FAILED
Build Logs (available for 30 days)

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

andrestone · 2020-05-06T10:40:41Z

I think it's desirable to deeply recurse to all nested stacks and not just children of the top-level stack.

Done!
Thanks for reviewing.

PS: Will try to cover other related issues in this PR.

aws-cdk-automation · 2020-05-06T11:18:09Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 7f1fc96
Result: SUCCEEDED
Build Logs (available for 30 days)

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

aws-cdk-automation · 2020-05-06T11:52:02Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 1e72cfc
Result: SUCCEEDED
Build Logs (available for 30 days)

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

…urces

aws-cdk-automation · 2020-05-08T19:02:26Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 93dd0bc
Result: FAILED
Build Logs (available for 30 days)

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

andrestone · 2020-05-08T19:05:46Z

@eladb @shivlaks I guess I might have gone too far already.

I'd appreciate some feedback before running more integration tests.

shivlaks · 2020-05-08T19:43:02Z

@andrestone I've added this PR to my list of things to get through. stay tuned!

damonmcminn · 2020-05-19T09:02:23Z

This feature is incredibly important to me: current process requires deploying and manually checking CloudFormation UI for changes as my CDK app is a composition of nested stacks.

If I can in any way assist this PR to expedite it's approval, please let me know.

shivlaks · 2020-05-19T09:15:06Z

@damonmcminn I'll start reviewing it tomorrow. You are more than welcome to help and provide feedback!

A good starting point might be to just pull this PR down to build it and use it locally. I haven't played enough with Nested Stacks so that'll be an exercise I will be going through as well.

It will help with providing feedback on the experience, usability gaps, wishlist, etc.

shivlaks · 2020-05-19T09:18:23Z

I'd appreciate some feedback before running more integration tests.

@andrestone good call. we recently changed all the CLI tests to leverage jest rather than the scripts that were there previously.

andrestone · 2020-05-19T12:00:20Z

@shivlaks

I'll start reviewing it tomorrow. You are more than welcome to help and provide feedback!

Ping me if you want to chat or something. The less semantic portion of the PR is what makes it backwards compatible by inferring the deeply nested stacks relation to their parent resource (it uses the S3 version Key reference present in the asset).

There are many improvements that can be done, but I guess the PR deservers conceptual / design review first.

damonmcminn · 2020-05-20T06:51:30Z

@damonmcminn I'll start reviewing it tomorrow. You are more than welcome to help and provide feedback!

A good starting point might be to just pull this PR down to build it and use it locally. I haven't played enough with Nested Stacks so that'll be an exercise I will be going through as well.

It will help with providing feedback on the experience, usability gaps, wishlist, etc.

I'll get on this today and see what feedback I can provide: at a minimum I'll be able to provide something on the UX. Thanks @andrestone for doing this!

damonmcminn · 2020-05-20T11:52:16Z

This has been my process:

my app was version 1.39.0
I ensure the app is up-to-date and has no changes
I downgrade to 1.38.0 to match version of this PR
I run cdk deploy to ensure metadata is set from 1.38.0
I again ensure the app is up-to-date and has no changes
I clone this repo and checkout this branch
I run yarn build which fails due to this error:

@aws-cdk/aws-iam: Error: Some stacks have changed. To verify that they still deploy successfully, run: 'npm run integ integ.composite-principal.js integ.group.js integ.managed-policy.js integ.oidc-provider.js integ.policy.js integ.role.js integ.user.js integ.users-and-groups.js'

I use this repo's packages/cdk/bin/cdk in place of my app's local version to diff:
- /path/to/this/packages/cdk/bin/cdk diff

Expected: no changes or metadata changes only
Actual: output shows that (practically) the whole infrastructure will be recreated

I am not at liberty to share the output of running the command, but am happy to share privately.

andrestone · 2020-05-20T12:25:38Z

This has been my process:

my app was version 1.39.0

I ensure the app is up-to-date and has no changes

I downgrade to 1.38.0 to match version of this PR

I run cdk deploy to ensure metadata is set from 1.38.0

I again ensure the app is up-to-date and has no changes

I clone this repo and checkout this branch

I run yarn build which fails due to this error:
@aws-cdk/aws-iam: Error: Some stacks have changed. To verify that they still deploy successfully, run: 'npm run integ integ.composite-principal.js integ.group.js integ.managed-policy.js integ.oidc-provider.js integ.policy.js integ.role.js integ.user.js integ.users-and-groups.js'
I use this repo's packages/cdk/bin/cdk in place of my app's local version to diff:

/path/to/this/packages/cdk/bin/cdk diff

Expected: no changes or metadata changes only
Actual: output shows that (practically) the whole infrastructure will be recreated

I am not at liberty to share the output of running the command, but am happy to share privately.

I'll merge changes so you can clone the repo, build on master and then use build up from the changed packages only.

The deeply nested stack might have their parent resources recreated as the hash might have changed due to the metadata field now present in the template.

As mentioned before, I'm not sure this is the best way to represent this relation.

shivlaks

@andrestone I'm not close to being done - but I've started and will continue. review fatigue catches up with me after about an hour. I pinged you and hope we can talk through some of this stuff.

A general thought that occurred to me is whether we can scaffold this feature out in a meaningful way or do you see this entire feature list as being an all or nothing. I think we can work through it a bit faster if we can break up the PR into smaller chunks.

shivlaks · 2020-05-20T22:26:50Z

packages/@aws-cdk/core/lib/nested-stack.ts

+    Stack.of(this).templateOptions.metadata = {
+      [cxapi.PATH_METADATA_KEY]: this.node.uniqueId,
+    };


worth a comment to explain why it's needed and what it represents

shivlaks · 2020-05-20T22:27:10Z

packages/aws-cdk/lib/api/cloudformation-deployments.ts

@@ -127,6 +128,50 @@ export class CloudFormationDeployments {
    return stack.template();
  }

+  public async readCurrentNestedStackTemplates(stackArtifact: CloudFormationStackArtifact): Promise<Array<{


add docs strings

shivlaks · 2020-05-20T22:31:19Z

packages/aws-cdk/lib/api/cloudformation-deployments.ts

+      if (e.code === 'ValidationError' && e.message === `Stack with id ${stackArtifact.stackName} does not exist`) {
+        return new Array<{ parentPath?: string, parentResourceId: string, template: Template }>();
+      }


add a debug statement here to capture that we've swallowed up the exception.
it should describe what we interpret this state to be. might be a useful marker when we debug.

shivlaks · 2020-05-20T22:34:00Z

packages/aws-cdk/lib/api/cloudformation-deployments.ts

+      }
+    }
+
+    return ret;


this feels like a long method, what do you think about refactoring some functionality out

shivlaks · 2020-05-20T22:40:39Z

packages/aws-cdk/test/integ/cli/test-cdk-diff-with-nested-stack.sh

@@ -0,0 +1,16 @@
+#!/bin/bash


these will need to be updated now that all our integ tests are run through Jest

shivlaks · 2020-05-20T22:52:33Z

packages/aws-cdk/lib/api/util/cloudformation/stack-activity-monitor.ts

+    try {
+      return await this.cfn.describeStackEvents({StackName: stackName, NextToken: nextToken}).promise();
+    } catch (e) {
+      if (e.code === 'ValidationError' && e.message === `Stack [${this.stackName}] does not exist`) {


we're using a similar check in cloudformation-deployments, can we DRY it up a bit?

shivlaks · 2020-05-20T22:52:46Z

packages/aws-cdk/lib/api/util/cloudformation/stack-activity-monitor.ts

    }

    return events;
  }
+
+  private async readCfnEvents(stackName: string, nextToken: string | undefined) {


Suggested change

private async readCfnEvents(stackName: string, nextToken: string | undefined) {

private async readCfnEvents(stackName: string, nextToken?: string) {

shivlaks · 2020-05-20T23:11:11Z

packages/aws-cdk/lib/cdk-toolkit.ts

+    const ret = new Array<{ parentPath?: string, parentResourceId: string, template: any }>();
+    const resources = [{resources: stack.template?.Resources, parentStackResources: {} as any, parentStackId: stack.stackName}];
+    const nestedStackAssets = stack.assets.filter((ast) => {
+      return ast.path && ast.path.includes('nested.template.json');


are these being read from the location pointed to by the manifest.json file?

shivlaks · 2020-05-20T23:16:41Z

packages/aws-cdk/lib/cdk-toolkit.ts

+  private findS3VersionKeyForNestedStackResource(
+    running: { resources: any; parentStackId: string; parentStackResources: any },
+    key: string,
+    resources: Array<{ resources: any; parentStackId: string; parentStackResources: any }>) {
+    const url = JSON.stringify(running.resources[key].Properties?.TemplateURL);
+    let s3Key = url.match(/\w+S3VersionKey\w+/g)?.[0];
+    if (!!s3Key && s3Key.includes('referenceto')) {
+      if (Object.keys(running.parentStackResources[running.parentStackId].Properties?.Parameters || {}).includes(s3Key)) {
+        s3Key = running.parentStackResources[running.parentStackId].Properties?.Parameters[s3Key].Ref;
+      }
+      if (!!s3Key && s3Key.includes('referenceto')) {
+        let resUtil = [...resources];
+        while (resUtil.length > 0) {
+          const res = resUtil.pop() as any;
+          if (Object.keys(res.parentStackResources[res.parentStackId]?.Properties?.Parameters || {}).includes(s3Key!)) {
+            s3Key = res.parentStackResources[res.parentStackId].Properties?.Parameters[s3Key!].Ref;
+            if (s3Key!.includes('referenceto')) {
+              resUtil = [...resources];
+            } else {
+              break;
+            }
+          }
+        }
+      }
+    }
+    return s3Key;


I think it's worth breaking the nested stack parsing out into it's own class so it's more unit-testable. Relying on integ tests has put us in a place that we would like to get out of by raising the unit test coverage.

andrestone · 2020-05-21T13:09:54Z

@andrestone I'm not close to being done - but I've started and will continue. review fatigue catches up with me after about an hour. I pinged you and hope we can talk through some of this stuff.

A general thought that occurred to me is whether we can scaffold this feature out in a meaningful way or do you see this entire feature list as being an all or nothing. I think we can work through it a bit faster if we can break up the PR into smaller chunks.

@shivlaks Thanks for reviewing. I'll try to get back to this by the weekend.

However, I'd like to be sure the concept is understood and accepted, before working on optimisations.

Key points here are:

This introduces a Metadata field in every nested stack template, referring to the parent stack resource logical id (to bind nested stack to parent stack for everything diff related)
There's a relatively complex / hacky inference logic built as an attempt to support existent / deployed nested stacks. I'm not sure this is useful since the nested stack would be recreated on first deploy, as the template will be different (Metadata field).
If nested stacks are shown by default on synth / diff, we'll need to overwrite all / many expected outputs for integration tests. Is it desirable?

It would be nice to have these settled before refactoring / cleaning.

shivlaks · 2020-05-21T17:18:15Z

@andrestone absolutely, I didn't realize it publishes all the other comments. They're just noise right now and I wouldn't prioritize them as they're mainly style/organization. intended to only publish the summary comment. sorry about that!

I'm basically writing up a mini-RFC and starting to play with it locally to go over the design, concepts, approach, and alternatives (haven't gotten to this yet). I do think this particular issue requires this exercise. Absolutely agree that the approach is the #1 thing to review and validate here.

armilam · 2020-06-19T18:05:24Z

It's been 29 days since the last activity on this PR and this is something I am very interested in using. Thank you all for the work so far. Is there any way that I can help keep it moving?

andrestone · 2020-06-20T09:42:52Z

It's been 29 days since the last activity on this PR and this is something I am very interested in using. Thank you all for the work so far. Is there any way that I can help keep it moving?

This PR is waiting for a conceptual review from the CDK team (ping @SomayaB).

It actually looks more like an RFC, even more so due to the volume of changes on the master branch.

shivlaks · 2020-06-22T14:44:56Z

It's been 29 days since the last activity on this PR and this is something I am very interested in using. Thank you all for the work so far. Is there any way that I can help keep it moving?

This PR is waiting for a conceptual review from the CDK team (ping @SomayaB).

It actually looks more like an RFC, even more so due to the volume of changes on the master branch.

@andrestone @armilam - sorry, I'd started the RFC and had to divert my attention. Thanks for the reminder, I'll pick this back up this week and get the RFC into a review where we can continue the discussion.

corrjo · 2020-08-14T19:45:33Z

Any update on this?

timpur · 2020-09-01T07:43:28Z

This would be a really nice feature to have soon :) any updates ?

thomaspoignant · 2020-09-11T07:40:30Z

Any updates? I still don't know if I should use a nested stack only for that reason.

andrestone · 2020-11-19T12:14:18Z

This PR is obsolete due to new CloudFormation support for nested stack change sets: https://aws.amazon.com/about-aws/whats-new/2020/11/aws-cloudformation-change-sets-now-support-nested-stacks/

timpur · 2020-11-23T00:34:28Z

@andrestone when will we see that feature (CloudFormation support for nested stack change sets) make its way into cdk to resolve this ticket ?

andrestone force-pushed the andrestone/nested-stack-activity branch 2 times, most recently from 8356bf7 to a3bd47e Compare May 5, 2020 17:40

SomayaB assigned eladb May 5, 2020

eladb changed the title ~~fix(core): display activity status for nested stacks~~ fix(cli): display activity status for nested stacks May 6, 2020

eladb assigned shivlaks and unassigned eladb May 6, 2020

eladb previously requested changes May 6, 2020

View reviewed changes

packages/aws-cdk/test/integ/cli/test-cdk-nested-stack-status.sh Outdated Show resolved Hide resolved

packages/aws-cdk/lib/api/util/cloudformation/stack-activity-monitor.ts Outdated Show resolved Hide resolved

andrestone force-pushed the andrestone/nested-stack-activity branch from a3bd47e to eaf88fe Compare May 6, 2020 09:06

andrestone force-pushed the andrestone/nested-stack-activity branch from eaf88fe to 7f1fc96 Compare May 6, 2020 10:33

andrestone requested a review from eladb May 6, 2020 14:03

andrestone changed the title ~~fix(cli): display activity status for nested stacks~~ feat(cli): improved interactions for NestedStack resources May 6, 2020

andrestone marked this pull request as draft May 6, 2020 14:26

andrestone changed the title ~~feat(cli): improved interactions for NestedStack resources~~ (WIP) feat(cli): improved interactions for NestedStack resources May 6, 2020

andrestone changed the title ~~(WIP) feat(cli): improved interactions for NestedStack resources~~ (WIP) feat(cli): improved interactions for NestedStack and NestedStack resources May 6, 2020

andrestone marked this pull request as ready for review May 6, 2020 23:22

feat(cli): improved interactions for NestedStack and NestedStack reso…

93dd0bc

…urces

andrestone force-pushed the andrestone/nested-stack-activity branch from 1e72cfc to 93dd0bc Compare May 8, 2020 18:56

andrestone changed the title ~~(WIP) feat(cli): improved interactions for NestedStack and NestedStack resources~~ feat(cli): improved interactions for NestedStack and NestedStack resources May 8, 2020

shivlaks reviewed May 20, 2020

View reviewed changes

Patrick-56Bit mentioned this pull request Jul 4, 2020

Nested Stack Change Set Evaluation aws-cloudformation/cloudformation-coverage-roadmap#142

Closed

timpur mentioned this pull request Aug 19, 2020

Show Diff in CDK Pipeline before deploying cdk-cosmos/cosmos#179

Closed

andrestone closed this Nov 19, 2020

	private async readCfnEvents(stackName: string, nextToken: string \| undefined) {
	private async readCfnEvents(stackName: string, nextToken?: string) {

feat(cli): improved interactions for NestedStack and NestedStack resources #7805

feat(cli): improved interactions for NestedStack and NestedStack resources #7805

Conversation

andrestone commented May 5, 2020 • edited Loading

Commit Message

End Commit Message

This is a WIP

Todo

Discussions

Immutable nature of Assets and NestedStacks traceability

NestedStacks verbosity on cdk synth

NestedStacks and the done / total info on cdk deploy

Details

cdk deploy and cdk destroy CloudFormation status updates (#7699, #5974, #6402)

cdk deploy security-impacting changes (#4490)

cdk diff (#5722)

cdk synth

aws-cdk-automation commented May 5, 2020

AWS CodeBuild CI Report

andrestone commented May 5, 2020

aws-cdk-automation commented May 5, 2020

AWS CodeBuild CI Report

aws-cdk-automation commented May 5, 2020

AWS CodeBuild CI Report

eladb left a comment

Choose a reason for hiding this comment

aws-cdk-automation commented May 6, 2020

AWS CodeBuild CI Report

andrestone commented May 6, 2020 • edited Loading

aws-cdk-automation commented May 6, 2020

AWS CodeBuild CI Report

aws-cdk-automation commented May 6, 2020

AWS CodeBuild CI Report

aws-cdk-automation commented May 8, 2020

AWS CodeBuild CI Report

andrestone commented May 8, 2020

shivlaks commented May 8, 2020

damonmcminn commented May 19, 2020

shivlaks commented May 19, 2020

shivlaks commented May 19, 2020

andrestone commented May 19, 2020

damonmcminn commented May 20, 2020

damonmcminn commented May 20, 2020

andrestone commented May 20, 2020 • edited Loading

shivlaks left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrestone commented May 21, 2020 • edited Loading

shivlaks commented May 21, 2020

armilam commented Jun 19, 2020

andrestone commented Jun 20, 2020

shivlaks commented Jun 22, 2020

corrjo commented Aug 14, 2020

timpur commented Sep 1, 2020

thomaspoignant commented Sep 11, 2020

andrestone commented Nov 19, 2020

timpur commented Nov 23, 2020

andrestone commented May 5, 2020 •

edited

Loading

NestedStacks verbosity on `cdk synth`

NestedStacks and the done / total info on `cdk deploy`

`cdk deploy` and `cdk destroy` CloudFormation status updates (#7699, #5974, #6402)

`cdk deploy` security-impacting changes (#4490)

`cdk diff` (#5722)

`cdk synth`

andrestone commented May 6, 2020 •

edited

Loading

andrestone commented May 20, 2020 •

edited

Loading

andrestone commented May 21, 2020 •

edited

Loading