No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Hi. Once you've imported it into the Pulumi stack, Pulumi takes ownership so if you destroy your Pulumi stack then the LB will be deleted.

You can then remove the resource from the stack once you've finished with it

So the flow would be, import the LB, mutate the Listener, use it, then when the test cluster is no longer used, mutate the Listener back and remove the LB from the stack, then delete the stack, thanks.

Does this change significantly if I have another stack managing the LB, can the Listener be managed by more than one stack at once?

It can be, but you'll be over writing it when you deploy from one to the other

Is there any reason why you'd want to _not_ create, update and destroy with Pulumi rather than using the console?

So each stack would need to import the current state and the mutate it, I guess. Ok thanks, food for thought.

No reason, but it has already happened. I built the Infra by clicking things in the console. Now I want to use Pulumi to enable launching adhoc test environments using containers built from feature branches, but to avoid having to do DNS fiddles I can use the *.test LB which I created by hand.

The next step would be to write the stack to manage the already built infra, hence the question about mutiple stacks managing the same listener

I could also just make a new LB for each adhoc test, but I wanted to know if the other way was possible.

So the beauty of Pulumi is that you can import resources bit by bit and take over the management from the console to Pulumi.