Automating the Challenge Lab seemed a bit time sensitive for me so I had to change some orders and put in some sleep time?
1 Answers
Good for you, Mark! You now have first-hand experience with the asynchronous nature of these systems! 😀 And not only are the systems inherently asynchronous, different commands will act a bit differently in this regard. For example, by default gcloud compute instances create will delay its return until the instance has entered the RUNNING state:
When an instance is in RUNNING state and the system begins to boot, the instance creation is considered finished, and the command returns with a list of new virtual machines. But if you pass that command the --async flag, then it will:
Display information about the operation in progress, without waiting for the operation to complete.
That said, you’re still on your own if you want your script to wait until the startup script you pass it has finished. There’s no flag for that. So if you want your script to move on to deleting the instance after starting it up, you’ll have to make it wait, somehow.
Now, when dealing with asynchronous processes like this, it’s always best practice to rely on something meaningful happening rather than on some time elapsing. For example, you could have your script watch for the log file to show up in the bucket (have it 1. sleep a little, 2. check for the file, 3. repeat the loop or move on) and use that to synchronize your script to what’s happening on the GCE instance.
But for a learning lab like this, it is of course perfectly fine to do whatever works and optionally look further into the semantic waiting in the future! 😁
Do you feel that these exercises are helping you learn how to wield these tools?
Cheers!
Mattias