hi team, I am building a comprehensive component f...
# general
f
hi team, I am building a comprehensive component for aws vpc and wanted your feedback about something. imagine you want to customize your route tables and you want to encode references to other objects inside your inputs. I want to support: • reference to objects defined as part of the same stack (e.g. other subnets, attachments, igw/vgw, etc.) • reference to arbitrary objects by id - this is simple, just put id • reference to an object based on tag(s) • reference to an object based on ssm value here is what I came up with (yaml):
Copy code
subnets:
  - name: ext-az1
    ...
  - name: ext-az2
    ...
attachments:
  - name: tgw-attachment
    # some parameters
  - name: cwan-attachment
    # some parameters
routeTables:
  - name: private
    routes:
      - destination: 0.0.0.0/0
        nextHop: igw
      - destination: ::/0
        nextHop: igw
      - destination: 10.0.0.0/8
        nextHop: tgw@tgw-attachment  # or cwan@cwan-attachment
      - destination: subnet@ext-az1.ipv4
        nextHop: vpce-123456
      - destination: subnet@ext-az1.ipv6
        nextHop: vpce-123456
      - destination: 10.1.0.0/24
        nextHop: pcx@tag:Name=MyPeering,Environment=Prod
      - destination: 10.2.0.0/24
        nextHop: pcx@ssm:/my/peering/id
what do you think about the syntax? how would you improve it / make clearer for the user?
q
I'm personally more a fan of encoding this information (i.e. tags, ssm params, etc.) via types. That way it's more explorable in the IDE and documentation.
f
@quick-house-41860 could you give me an example?
q
The
nextHop
property could have typed inputs for the different things you can pass in. E.g.
Copy code
nextHop:
  igw:
    id: your-igw-id # reference by ID
    res: igw        # pass the actual resources
    tags:           # allow selecting it by tags
      ...
    ssm: param-name # SSM param
On the other hand, it would also be fine to just accept IDs in my mind and let users look up the IDs themselves via functions if they're not defined in the same stack 🤔
f
@quick-house-41860 I see, thanks. I was considering this, but it makes inputs too complex for user. cloudformation also implements at least ssm part
Copy code
{{resolve:ssm:/my-peering/id}}
in pulumi yaml, is there a way to do such lookup (e.g. ssm) and store it in the variable to be later used in component args?
q
Yes, you can perform that lookup using the SSM getParameter function: https://www.pulumi.com/registry/packages/aws/api-docs/ssm/getparameter/
f
thanks!