Repository navigation
Feature request: Add "wait for VM running" function #2015
Description
Activity
Thanks for the idea! What should happen if the user is accessing a VM that already exists? Do we call
getMetadata()in the background and execute the callback if it's running? If it's not running, do we start it for them?What should happen if the user is accessing a VM that already exists? Do we call getMetadata() in the background and execute the callback if it's running?
It should return consistent results, so if the VM already exists and is running, it should return the same results as if the VM was just spun up, so I'm guessing that would require a
getMetadata()call in the background. I know the reason that I would call this is because I'm waiting for the VM to be in a running state so that I know that I can get the metadata containing the external IP, and it's possible that the instance is already running and thestartVMoperation has completed by the time I get around calling it.If it's not running, do we start it for them?
It shouldn't by default, as the user is just waiting for it to be running under the assumption that it already
been started. Perhaps it could take in an "autostart" option, similar tovm.resize(), and set it tofalseby default?I like all of these ideas so far. The only thing I'd change is sticking with the
.on('event')style of registering event listeners.Would you like to start an implementation? I can help along the way as much or as little as necessary.
I can certainly give it a shot. I'll take a look this weekend.
Reacted by StephenI've gotten familiar with how the API internals work, and I've started implementing this. I have a few questions:
@stephenplusplus: You said you would like to stick to events for this. Do you mean that you would like for the vm object itself to emit an event (i.e. listening for the event by
vm.on('RUNNING', function(...)))?Also, would it be alright if I did both event emitting and a function with a callback? Say, user could register a listener which would initiate polling and then emit when the desired state is achieved, but could also call
waitFor('RUNNING'), which would do the same thing and just call the callback and/or resolve the promise.I think one method is enough, I chose 'on' because it is the familiar way of waiting for an event to complete for JS developers. We also use EEs in other places in our library. If the end goal is promise support for this method, are you sure .on wouldn't get "promisified"? I'm not sure what the other parts of our API do, or if it's expected for an EE to be compatible with promises. But feel free to send the PR and we can look at any specific issues that are coming up.
Thanks again for helping out!
This was added in #2047 -- yay!
- added 2 commits that reference this issue
on Feb 25, 2026 - added a commit that references this issue
on Mar 18, 2026
The AWS EC2 sdk has this really handy feature "waitFor": http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/EC2.html#waitFor-property
It calls the callback once the specified instances are in the specified state.
It would be handy to have this in the compute API, something like
vm.waitFor("RUNNING").then(...), instead of having to carry around the operation object returned fromcreateVM()and wait for the event to be emitted.