Skip to content
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

Support for custom resources #10

Open
udondan opened this issue May 6, 2021 · 2 comments
Open

Support for custom resources #10

udondan opened this issue May 6, 2021 · 2 comments

Comments

@udondan
Copy link

udondan commented May 6, 2021

I tried cdk-dia today and it looks great. One thing I noticed is, it skips custom resources.

Already tried to look into this but it appears this is not so easy to implement. I haven't figured out where custom resources are filtered from generation. Adding them to the awsResouceIconMatches.json seems to not fix it (it would not be a solution anyway, since the name isn't static. Just did that for a quick test) Somehow they're filtered before they reach the AwsIconSupplier.matchIcon() call but I was not able to figure out how this morning.

@udondan
Copy link
Author

udondan commented May 7, 2021

If I understand the code in 6d689c3 correct, it looks for AWS::CloudFormation::CustomResource. That's one way to define custom resources. The other way is Custom::xxx where the xxx can be any string.

For my custom resources it looks more like this:

{
  "Resources": {
    "TestKeyPairEC2KeyPairtestkeypair8B76C420": {
      "Type": "Custom::EC2-Key-Pair",
      "Properties": {
        "ServiceToken": {
          "Fn::GetAtt": [
            "EC2KeyNameManagerLambdaBE629145",
            "Arn"
          ]
        },
        "Name": "test-key-pair",
        "Description": "A test Key Pair",
        "KmsPrivate": "alias/aws/secretsmanager",
        "KmsPublic": "alias/aws/secretsmanager",
        "StorePublicKey": false,
        "ExposePublicKey": true,
        "RemoveKeySecretsAfterDays": 0,
        "SecretPrefix": "ec2-ssh-key/",
        "StackName": "EC2KeyPair",
        "Tags": {
          "a": "b",
          "c": "d",
          "CreatedByCfnCustomResource": "CFN::Resource::Custom::EC2-Key-Pair",
          "Hello": "World"
        }
      },
      "UpdateReplacePolicy": "Delete",
      "DeletionPolicy": "Delete",
      "Metadata": {
        "aws:cdk:path": "EC2KeyPair/Test-Key-Pair/EC2-Key-Pair-test-key-pair/Default"
      }
    }
     ...
  }

This is from one of my custom constructs cdk-ec2-key-pair.

@pistazie pistazie reopened this May 8, 2021
@pistazie
Copy link
Owner

pistazie commented May 8, 2021

cdk-dia generates a diagram from the construct-tree (./cdk.out/tree.json). It doesn't parse the actual cloudformation template so it can't search for Custom::xxx.

looks like the CDK team built a "custom resource framework" and it's being processed after the construct-tree is generated.
therefore my solution was (what the commit does) is to identify "constructInfo": { "fqn": "@aws-cdk/core.CustomResource", "version": "1.102.0" } and converts it to a AWS::CloudFormation::CustomResource so it's in the diagram.

What would your best-case diagram for the construct look like?

In my opinion, constructs should usually be collapsed by default so the diagram contains one node/icon with a label "test-key-pair custom resource" and the construct's implementation is abstracted (the user used a construct library). reaching this result with your construct is tricky because some of the resources are binded to the construct (e.g. new cdk.CustomResource(this,...) and some resources are "leaked"/binded to the stack? (e.g. new iam.ManagedPolicy(stack, ...).

Additionally, in order to collapse constructs I used a convention used by cdk where the "main" resource of each construct is has the id resource.

When one uses cdk-dia with the --collapsed false flag then the construct should be a cluster (basically a frame) with all provisioned resources inside it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants