Hi folks. My lead eng is on vacation so I'm trying to figure this out and hopefully someone here can help. My

pulumi up

command is hanging and not responding to ctrl-C, ctrl-\, or any other commands I'd usually try to kill the process. I'm using a super basic stack configuration just to try to figure out what's going on:

"""An AWS Python Pulumi program"""

import pulumi
from pulumi_aws import s3

# Create an AWS resource (S3 Bucket)
bucket = s3.BucketV2('my-bucket')

# Export the name of the bucket
pulumi.export('bucket_name', bucket.id)

And this is what I'm seeing on my screen after more than 1 hour of waiting. I'm assuming this is a configuration issue but shouldn't I get an error message or something? Why would it be locked up like this on such a basic implementation?

I don't know why it wouldn't respond to an interrupt or kill, unless maybe you're using a browser-based terminal that's not passing those signals on to the terminal? As to why it might be hanging like that: given what I can see on the terminal, my guess is that your stack uses short-lived sessions (e.g. via SSO) and the current session has ended. I don't know why the AWS SDK just hangs like that when dealing with expired short-lived sessions, but that's what it does for me. You may need to run

aws sso login

or some equivalent.

Hi @little-cartoon-10569 thanks for hopping in. I'm indeed using aws SSO, but I'm running

aws sso login

immediately before running

pulumi up

so I wouldn't expect that to be the issue. Also just running in iTerm on my macbook.

Have you confirmed that your stack config is using the short-lived session? For example, if it is hard-coded to use profile X and you're using the default profile, then the short-lived session won't be picked up. You'd have to run

aws --profile X sso login

to get it to work in that case.

Right, I'm running

aws sso login --profile my-profile

. I just created this stack - where would I look to check if it's using a short-lived session?

In your Pulumi.yaml, Pulumi.<stack>.yaml, or your AWS provider constructor in code. You're looking for the AWS provider config: is it specifying a profile? Or maybe the env vars?

Yeah I'm trying literally with the base aws-python template just to narrow it down. Here's my Pulumi.yaml:

name: test3
description: A minimal AWS Python Pulumi program
runtime:
  name: python
  options:
    toolchain: pip
    virtualenv: venv
config:
  pulumi:tags:
    value:
      pulumi:template: aws-python

No, you don't need the env var, unless the provider is explicitly referring to it. If it's the default provider or falling back via the normal precendence, then simply specifying the prlfile should be good.

Just this:

config:
  aws:region: us-east-1

Right. Is the AWS provider constructed in your project code? If not, then you're using the default profile. In which case, try

aws sso login

again, without the

--profile

.

But I'm confused to why it would hang as opposed to saying it can't access s3 or whatever the first error would be

Where does it say that?

Aha, ok the provider is not explicit in my project code. That might be what I'm missing

It's ok to use the default provider. I don't, but it does work. Just don't specify a profile when you're logging in, and it should be good.

Well my default provider on my machine is using creds that no longer exist, that must be what's going on. Let me see about specifying the profile explicitly in my code

Yea, you'll need something to map your sso_session to the default provider, else it won't be looking in the right place.

Yeah it's been a while for me too

No sorry, I've never looked into that.

yep, that’s all working fine

I suppose

pulumi login

might be worth a try too?

I looked into it some more online - I have an M1 mac, but the pulumi binary and aws provider binary is x86_64, which I’m guessing is because I have rosetta 2 enabled. I did all this a few years ago back when not everything supported the M1 architecture yet. Maybe this has something to do with it?

You're outside my area of expertise now. Worth a shot, re-install Pulumi for Apple hardware

That was it

I'm curious to learn how you discovered that you're running x86_64 versions of

pulumi

and the AWS provider. We've been thinking about adding detection mechanisms for this right into pulumi: https://github.com/pulumi/pulumi/issues/16598

@quick-house-41860 so here’s what I did: • I had an older version of Pulumi installed from a few years ago. When I went to run it, it prompted me to upgrade (using homebrew) • Went through that process above, then decided to remove Pulumi via homebrew and install it via the script at get.pulumi.com. Ran into the same issue w/ hanging after it installed the aws provider. • Seems like that also installed it (both the pulumi binary and aws provider) as x86. The way I found out was I just ran

which pulumi

, navigated to that folder, and then ran

file pulumi

and it told me it was x86. I then went into the plugins folder and did the same thing and saw that it was also x86. • From there I just removed the entire

~/.pulumi

folder, then I downloaded that script from get.pulumi.com and added some print lines to where it figured out the arch. • Unclear what I did to get it to work, but when I ran it locally using

zsh

instead of what’s in your documentation (

sh

), it installed correctly as arm64 and everything started working.

Thanks! I wonder if you've changed the arch of

sh

to x86 🤔 I remember that this was the workaround for some tools when the apple silicon macbooks first came out.

That sounds like the likely culprit. I did just check what architecture my

sh

command thinks it’s running in and it’s giving me arm64, but I’m not entirely sure how all of that works with Rosetta.

jason@Jasons-MacBook-Pro-2 datahub % /bin/sh
sh-3.2$ uname -a
Darwin Jasons-MacBook-Pro-2.local 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000 arm64