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

best-summer-38252

12/04/2021, 4:10 AM
Anyone skip the backend and secrets provider abstractions and interact with internals directly? For example, for the backend we can only configure a URL and the SDK will for the resource over the network, but I'd like use my own state store rather in code.
r

red-match-15116

12/04/2021, 4:12 AM
like you want to use local state?
b

best-summer-38252

12/04/2021, 4:20 AM
The only option i see right now is localworkspace, export the stack, and then push it to my k/v. Id rather not hit the filesystem and I'd like update the state store as it changes rather than all at once at the end of a transaction.
I was kind of hopping I would be able to provide a handler func but limited to:
Copy code
export interface ProjectBackend {
    url?: string;
}
r

red-match-15116

12/04/2021, 4:25 AM
yeah, you can only use the pulumi-supported backends via the exposed API - https://www.pulumi.com/docs/intro/concepts/state/#logging-in
b

best-summer-38252

12/04/2021, 4:43 AM
Ha ha this will level my expectations: the automation api is just a wrapper that runs the pulumi binary in a child process: https://github.com/pulumi/pulumi/blob/master/sdk/nodejs/automation/cmd.ts#L55
r

red-match-15116

12/04/2021, 4:44 AM
indeed
p

prehistoric-nail-50687

12/06/2021, 8:58 AM
@best-summer-38252 you might wanna follow this issue: https://github.com/pulumi/pulumi/issues/4605
b

best-summer-38252

12/06/2021, 4:20 PM
Nice and thank you @prehistoric-nail-50687 Im now subscribed. My take away to using file-based in object storage was to have tiny plans in anticipation of failure. Learning the SDK is a wrapper around the CLI dramatically lowered expectations. On how we can interact with Pulumi in our platform. I did not want to depend on k8s but perhaps I should be more open tech like Crossplane and OAM.
f

famous-leather-94346

12/08/2021, 2:50 PM
@best-summer-38252 IMO I wouldn't expect anything big from OAM. And Pulumi is opensource, you can do anything with it.
b

best-summer-38252

12/08/2021, 3:12 PM
@famous-leather-94346 as in make a TS native port instead of the CLI wrapper? I dont think that is a realistic contrib and it legit disappointment dispite the open source components. Pulumi's messaging around the Automation SDK was not a CLI wrapper. As for the the OP, any ideas on exposes the state internals in the CLI so the automation SDK could use a function rather than a object storage URL for the backend?
r

red-match-15116

12/08/2021, 3:37 PM
As for the the OP, any ideas on exposes the state internals in the CLI so the automation SDK could use a function rather than a object storage URL for the backend?
The internals (and CLI) are all written in go so this would have to be implemented across many components.
b

best-summer-38252

12/08/2021, 4:19 PM
Right. It not a matter of opening PR to scratch my own itch, it is inherent in the design. Lots of smart people have help create Pulumi and the Automation SDK. So Im questioning my desire to treat Pulumui state needs similar to my application state needs (db, redis, etc) vs treating it as repository more similar to an artifact store (GCS, S3...). I think there is an opportunity to speed things up but I more concerned recovering from a failure in the file based & repository-style state treatment. I think there are potential work-a-rounds. The disappointment with the CLI wrapper approach is: more about the next case(s) requiring work-a-rounds?
r

red-match-15116

12/08/2021, 4:29 PM
honestly i'm not really sure what you're asking - have you tried using it and has it failed you in any way?