Can Pulumi handle a circular `StackReference`, or ...
# general
m
Can Pulumi handle a circular
StackReference
, or will that break? I am trying to Create a Snowflake External Storage Integration using an AWS IAM Role, and they need to reference each other. Ideally, we would keep our Snowflake and AWS resources in separate stacks. Thanks!
l
If the two resources should be created together, then that sounds like they belong in the same project. You don't need to keep resources from different providers in separate projects. This is one of the major value adds of a tool like Pulumi: it allows you to define your higher-level services and resources without caring (from an external point of view) what lower-level services and resources implement them.
s
This blog post also discusses some other considerations for when resources should be in the same project or in different projects: https://www.pulumi.com/blog/iac-recommended-practices-structuring-pulumi-projects/ (you may find some useful information there)
m
Thanks! I put them in the same project. Still having issues though. Based on the docs (https://docs.snowflake.com/en/user-guide/data-load-snowpipe-auto-s3), it seems like a chicken-and-egg problem. The sequence is: 1. Create IAM Role 2. Create Snowflake Integration using the IAM Role ARN 3. Edit the IAM Role trust relationship to be conditional on the Snowflake Internal External ID But as far as I can tell, once I build a new IAM Role resource in Pulumi, there is no way to edit the trust relationship? Has anyone has any success making a working Snowflake to S3 Integration?
l
There is no way to edit the resource in a single run-through. Your options are: 1. Set the external ID to the value of an exported variable which is loaded from the stack's output. but does not use require. Set the variable to the correct output provided by Snowflake. Run
pulumi up
twice: when you run it the first time, the variable won't have a value (because the Snowflake integration hasn't been created), so the role will have the dummy ID in the trust policy. All subsequent runs will work correctly, as the value output from Snowflake will be available from the stack's outputs. 2. Use the wildcard trust:
If you require a trust policy with a less secure set of restrictions (i.e. a policy that supports all external stages in your account), replace random_id in the external ID with a wildcard character (*):
snowflake_account_SFCRole=snowflake_role_id_*, e.g. MYACCOUNT_SFCRole=2_* in the current example.
(See https://docs.snowflake.com/en/user-guide/data-load-s3-config-aws-iam-role)
I couldn't find a way to tell Snowflake what external ID to use, which would be the correct way to solve this problem generically.
You can use both of these solutions: if your default / dummy ID is the wildcard one, then your trust policy will always be correct. It just won't be totally restrictive initially.
m
Thanks for the detailed recommendations! Let me check and see what works for our use case
Thanks! Option 1 Worked!
s
Glad you were able to find a solution. Thanks @little-cartoon-10569!