https://pulumi.com logo
Join Slack
Powered by
question - we recently had to upgrade to `pulumi-a...
# aws
f
question - we recently had to upgrade to 
pulumi-aws@5.9.1
one thing we’re noticing is when executing pulumi from CI/CD, our runners didn’t need things like:
Copy code
ssm.get_parameter()
to explicitly need the aws provider or role to assume to function — it used to fall back to the default profile in the stack and assume the default profile’s role. Now we’re seeing that the pulumi_aws methods are attempting (and failing) to run w/o assuming the default profile. is there a graceful way for us to opt into that old functionality w/o going and passing the provider explicitly in all method calls?
man i’m not really sure how this worked previously, now that I’m reading this. i guess the TF docs are talking more about the provider specifically; i’m running into cases where i had multiple cases of 
method()
calls w/o a provider or parent passed into it, and it just worked
so, we actually have 
aws:profile
/ 
aws:region
in each stack’s config….hmm
ok maybe to rephrase this word spaghetti better it looks like, prior to upgrading (~ 
v4
), our project relied on the default aws provider to do its thing. so, we never needed to pass any named provider, bc the default provider was in scope at some point, after going to 
v5.x.x
, this default provider basically disappeared from the execution context, even though we have all the env vars and 
~/.aws/credentials
still in scope + unchanged
update: it’s the terraform authentication order thing. had to remove 
aws:profile
Open in Slack
PreviousNext
Powered by