I'm trying to "glue" together Pulumi (or any infra-as-code) code and application code. Traditionally if you have an app that needs an S3 bucket (or any other cloud resource) to store things, you would create that S3 bucket in Pulumi, and then pass the bucket's information to your app during the deployment (at least that's how most Terraform project I've worked on do things). The issue I have with this is that your Pulumi project, in a sense, has business logic that should be in the app itself. If my app now needs the S3 bucket to be public, I have to edit seperate Pulumi code. Any cleaner way to do this or am I trying to be too DRY?

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