This message was deleted.

Sounds like automation api is going to be your friend here

Seems like a huge shift, I'm very excited/interested about it! Cheers 😄

@brave-planet-10645 If the automation API was used to reconfigure an S3 bucket to be public, wouldn't the pulumi project code (that originally defined the S3 bucket) be out of date?

@green-musician-49057 so your automation api program is a replacement for your "standard" pulumi program. You can tell it to run a "standard" pulumi program (here's a good example of that) or you can just run your code as is (here's an example of that)

Got it -- so in Pier-Luc's example, the entire definition of that S3 bucket would be in their application code, using the automation API.

correct

Wouldn't miss it 😄

I'm really into lofi-type music at the moment (I find I can just have it on all day at work and it helps me concentrate) so I really liked it

One part I don't quite see how I'll do using this is subscribe to an SNS topic. If I do it using the automation API, my application would have to know that it is deployed before subscribing to the topic (because if it subscribes before being "live" (either from blue/green dpeloyments or even simple K8S rolling updates), SNS might send messages before the application can receive them

we built an abstraction model to do this. We have a pulumi program that builds about 15-20 different AWS API objects (dynamo, S3, SQS, SNS, etc etc). We defined a config schema and our developers include a yaml file in their repo that defines all the AWS infra they want for their app. It has its own pipeline so when they PR this yaml file, a pipeline runs that checks for or creates a new stack of that centralized pulumi program that runs just for their app and creates infra in each environment.

Yeah I can definitely see that working. Thanks for your input 😄

in some regards we re-implemented what the automation API is doing but in bash