is there a way to check the

pendingConfirmation

field of an

email

aws.sns.TopicSubscription

? pulumi seems to always be returning

true

, even if the subscription has been successfully confirmed

Does refreshing the resource change the value? You can target a

pulumi refresh

to a specific URN.

Yes I am also curious what pulumi refresh does. I suspect the state file says "pendingConfirmation" and it wouldn't know it has been confirmed until something like a pulumi refresh pushes it to sync state from AWS

💡 oh that's a great idea, let me try

Not sure, @blue-jelly-20468 would be in a better position to figure it out. "Changes" might mean "changes to cloud/provider"? I don't refresh frequently enough to remember...

So 'no changes' in this context means that if you ran pulumi up it would not make any changes to your stack

it absolutely makes sense, but i think it'd be nice if there were an option for

refresh

to log output changes as well!

Not particularly. Just grab the required values (ARNs or whatever) from Pulumi objects and pass them to the appropriate place in the SDK. You can put non-promise calls in

apply()

, or I prefer to expose Pulumi's

promise()

method and use that:

declare module "@pulumi/pulumi" {
  export interface OutputInstance<T> {
    promise(withUnknowns?: boolean): Promise<T>;
  }
}

That allows you to call

yourresource.itsproperty.promise()

and your Output is now a Promise. Which plenty of SDK functions work with. https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/welcome.html

is there any way to hook into pulumi

Plan

reporting to report changes to unmanaged resources? for example, i want to use the AWS SDK to delete the default VPC. i have something like the following:

if pulumi.runtime.is_dry_run:
        pulumi.log.info('preview delete default VPC')
      else:
        ec2.delete_vpc(VpcId=default_vpc_id)
        pulumi.log.info(f'Deleted default VPC {default_vpc_id}')

instead of using

pulumi.log

, is there any way to integrate into change reporting (so in this case pulumi would report

1 deleted

)? do i need to do something like... manually call

pulumi.runtime.registerResource

and then somehow mark it for deletion? or is this just not really something that's supported?

The default VPC is a managed resource 🙂 Also this would be what I'd consider "imperative" so I wouldn't put it in a Pulumi project at all -- maybe wrap a Pulumi project in an automation-api app and put this bit in there? As to the question: as far as I know, pulumi.log is it.

maybe i'm misunderstanding, but as far as i can tell, there's no way to programmatically delete the default VPC in pulumi - i'd have to add the managed resource, and then remove the managed resource, which i think is impossible to do in a single piece of code /

up

? i'd need to add the code, run

up

, then delete the code (with

force_destroy

) and run

up

again? that's not really a tenable process...

You can't imperatively delete anything using Pulumi code 🙂 You'd have to manage it then unmanage it. You could do this using the default VPC class: https://www.pulumi.com/registry/packages/aws/api-docs/ec2/defaultvpc/

but as mentioned above, that'd have to be done in two steps, right?

Yes. Deleting cannot ever be done in one step using Pulumi code.

So every time I make a new AWS account, in addition to making whatever change to create the account, I'd need to remember to make two additional code changes? That doesn't seem scalable/tenable

I would suggest not using Pulumi for this job. If you're creating an account, delete the default VPC manually or via an AWS (SDK) script.

Both options seem to defeat the whole purpose of having an IaC solution 😭

I am just catching up on this thread, but circling back, pulumi preview only shows diffs that will result in calls to the underlying provider. This is confusing and I am going to advocate for us to have another section on the preview that shows changes we are going to make to the state file and configuration even if they dont result in a call to the underlying cloud (although we will need to make it clear to users). Hope that helps clarify what preview is currently doing

i think that's an excellent idea!

Yeah I was thinking of a flag as well, but then I am worried people won't know to pass the flag and continue to be confused haha

oh and btw we're talking about

refresh

rather than

preview

right?

Well lots of these commands also invoke preview

ah. i'm not really aware how things work under the hood. i wasn't sure if

refresh

runs a

preview

or if it goes directly to the state file...

IDK on the exact behavior of refresh either haha

in this particular situation though, i think my confusion was with several things... 1. i guess i kind of forgot that once resources are created,

up

will work against the state file rather than fresh values. i wonder if there should be a flag

--refresh

or something on

up

that performs a refresh before proceeding (and maybe it just fails the operation if the refresh would make any changes). that way you're guaranteed that

up

is seeing the latest "real" state. i guess what i think would make sense is something like

pulumi refresh --preview-only --expect-no-changes && pulumi up

... except the docs for

--expect-no-changes

say

This check happens after the refresh is applied

which i think is kind of silly, there should be a way to do it before applying? 2.

refresh

making changes to the state without reporting it

Yeah I think we should consider it more too. I know another member of the team was just talking about how refresh is essential to run before certain operations and we should probably just incorporate that in some way into the pulumi CLI

it's definitely not trivial!!!

Did you know that there is a

--refresh

flag on the

up

command? It's like your mind has been read! ;)

🤦 TIL, thank you 😆