Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic VM ID generation #428

Open
miberecz opened this issue Oct 24, 2024 · 0 comments
Open

Dynamic VM ID generation #428

miberecz opened this issue Oct 24, 2024 · 0 comments

Comments

@miberecz
Copy link

miberecz commented Oct 24, 2024

Hello Everyone,

Its not a bug report, I'm just reaching out to get some help to solve a problem of mine.
If you can suggest better forum for this that already helps.

Right now, we are creating Virtual Machines on Proxmox using this provider with Go.
Iterating through a set of input files where different VM details are described, generating VirtualMachineArgs, running NewVirtualMachine on each.
Having different parameters defined by us is fine for the most part. Every VM has to have name, resource values, list of disk... etc.
Where my problem comes is the ID. If I change the ID of VM, then pulumi recreates the resource. Which is obviously not a desired outcome.
Okay, then do not change the ID you could say. And I do not want to.
But to dynamically generate the ID, I would have to re-calculate it every time we run 'pulumi up'.
The problem is, at the time of 'pulumi up' we cannot differentiate that its a creation of a new resource, or updating an already existing. Or we can, I'm just missing something.
There is this feature ignoreChanges, which works for most fields of the stack json, but not for the VMID, since its part of the resource URN. And not a solution, since I do not want to change the Id at the first place, so no point to ignore it anyways.

How could I only run a piece of code only at creation time, store the result somewhere, and later read the same parameter from that storage. Currently we do not use any sort of database apart from the pulumi stack file stored in S3, and we would like to keep this way unless there is no other option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant