https://pulumi.com logo
#automation-api
Title
# automation-api
i

icy-controller-6092

12/08/2023, 11:54 PM
Hi everybody! I'm using the automation api with some funky
local.Command
usage to manage custom resources that aren't supported by existing plugins, e.g. deploying a schema to a schema registry I have a lot of micro-stacks, and sometimes the existing resources are no longer applicable if I remove a service from the cluster - but the micro-stacks may still have resources from that service in their state, e.g.
Copy code
new local.Command('xyz', {
  delete: 'curl --fail -X DELETE <http://some.retired.service.local/...>'
})
If you retire the service before removing the resource from the state of every mini-stack, following deployments will fail because the delete command fails. To solve this, I've started using migration scripts to
stack.exportStack()
-> manual modifications ->
stack.importStack(newState)
which can be used to manually filter out resources from
state.deployment.resources
creating thread to avoid taking up too much space in main chat the migration scripts would be much easier to manage if I could store some kind of version number in the micro-stack's state to indicate which version of the deployment script the state represents, this will help me understand which migration steps need to be run for the micro-stack
is there any way to do this? I did think maybe I could just export
deployment_script_version
as a static string updated each time I need to bump, but I wasn't entirely sure if there isn't already an existing mechanism in place. thank you 🙏
l

little-cartoon-10569

12/09/2023, 12:25 AM
Yes, exporting is good for this. You can also export it as
readme
and it'll be displayed nicely in the Pulumi console
3 Views