This is not something I’ve experienced before

nothing, if kubernetes credentials in the stack are not working - stack is toasted. it wont let you do anything (destroy\refresh\update) because credentials do not work

same deal with the locked resources. I cant delete a stack with the locked resource. how much sense does it make? lol

Ah, I see what you mean - the provider cannot configure itself. cc @creamy-potato-29402 @gorgeous-egg-16927

how do i rebuild it?

Not being able to delete stacks with locked resources makes perfect sense to me

makes no sense to me

Anything else is not respecting the general definition of a “lock”

no, you lock the resource, NOT the stack

That doesn’t prevent concurrent modifications from two users simultaneously

what does this have to do with deleting the stack?

Deleting it is a modification of it

so? nowhere did I say anything about 2 users? how is this relevant?

besides it says "this doesnt prevent"

so i'm not sure what is this argument for

There are two separate issues here - one bug and one explanation of correct behaviour: The kubernetes provider not being usable in this case sounds like a bug to me (cc @gorgeous-egg-16927 and @creamy-potato-29402 who can investigate that one). The reason you can’t continue in some (not all) circumstances when an update/destroy is terminated non-gracefully is because of the per-stack state lock. The state lock exists such that two users can safely run

pulumi up

and know that their runs will be serialized. You don’t actually have to have two users for this to present, however - since there is no way for us to know when a second user is about to appear, the lock is used at all times. The “this doesn’t prevent” refers to a per-resource lock instead of a per-state lock.

unknown state, lol. a simple get to the azure api would reveal the mystery behind unknown state

this means I cant run the pipeline, this means I'd need to intervent manually. at this point I really start to contemplate getting back to arm templates

this is not the first time i'm going through this, lol. i'm constantly battling pulumi to update my stack. its like every time a do a change thats more than 2 lines, blam. nothing works

I'd have no idea how to use this for anything serious

Personally I can’t suggest anything else here - I’ve not experienced these problems on any infrastructure including very large stacks. Perhaps @big-piano-35669 or @white-balloon-205 can help here?

@little-river-49422 I'll follow up in DM - would like to understand more details on the problems you are seeing here.

Hi there, is

register_outputs()

mandatory in a

ComponentResource

to use a variable output in another top level resource ? or can i reference directly the

ComponentResource

class property ?

Posting here if someone have an idea on how to do this

hey folks, Luke** doesnt seem to respond, any ideas on the issue I talked with him? were you able to repro?

jesus, my typos are getting ridiculous

I can't find this terraform resource in pulumi-aws https://www.terraform.io/docs/providers/aws/r/default_vpc.html Are these "advanced" resources available yet in pulumi?

With terraform, we can use

count

to create a loop for creating resources. I'm able to get the output of those resources in a list with the following.

output "public_subnet_ids" {
  value = ["${aws_subnet.public.*.id}"]
}

I'm trying to replicate this behavior with pulumi but cannot figure out how to get the same output list using export. I'd appreciate any help.

You can use a list comprehension

pulumi.export("public_subnet_ids", [sn.id for sn in self.public_subnets])

for example