Improve setup readiness with provider-specific signals

[madebygps]

Summary

Track a future improvement to replace the current cross-cloud SSH marker wait with provider-specific readiness signals where each cloud supports them.

Background

Release-mode setup runs through first-boot scripts. That keeps the setup package small and avoids uploading local files for learners, but the cloud VM resource can report as created before the CTF setup is complete. The current fix should use a consistent marker-based readiness wait so learners do not SSH into a half-configured VM.

Future provider-specific options

• Azure: investigate moving release setup, or a setup-complete check, to Azure VM Custom Script Extension so Terraform can use extension provisioning status.
• AWS: investigate AWS Systems Manager Association or Run Command with success waits. This likely requires SSM agent readiness, IAM instance profile, and network access to SSM endpoints.
• GCP: research whether OS Config, guest attributes, or another Google-native signal can provide a clean setup-complete wait. Startup scripts alone do not appear to provide Terraform-native completion readiness.

Acceptance criteria

• Document which provider-native readiness paths are viable and what extra permissions or infrastructure they require.
• Prefer native success/failure status over blind sleeps.
• Keep learner deployment simple. Do not add provider-specific complexity unless it improves reliability enough to justify it.
• Preserve contributor-mode testing behavior.

Related to #81.

[madebygps]

@rishabkumar7 Hey Rishab! This is GPS — I'm assigning this one to you because you're the Terraform guru 🚀. This issue is about improving setup readiness with provider-specific signals (Azure VM Custom Script Extension, AWS SSM, GCP guest attributes, etc.). Let me know if you have any questions or need context!

[rishabkumar7]

will check it out and let you know @madebygps if I have any questions. 🚀

[rishabkumar7]

Provider-native readiness findings

We reviewed the current release-mode readiness flow and provider-native alternatives.

Findings

• The current cross-cloud SSH marker wait should remain the default for now. It is simple, consistent across AWS/Azure/GCP, and does not add learner-facing cloud setup complexity.
• Azure is the strongest provider-native candidate. Azure VM Custom Script Extension can expose setup success/failure through Terraform extension provisioning status, so it is worth prototyping as a cleaner release-mode readiness path.
• AWS Systems Manager is viable but adds IAM instance profiles, SSM managed-node readiness, agent/network endpoint dependencies, and more troubleshooting surface. It does not look like a good default learner path yet.
• GCP guest attributes can provide a useful status signal, but they still require polling glue from Terraform or local tooling. They are not a clean native replacement for the marker wait by themselves.
• Contributor mode should be preserved exactly: use_local_setup=true should continue uploading and running local files through the existing test path.

Follow-up work

Opened #100 to prototype the Azure-only path with azurerm_virtual_machine_extension in release mode. That issue should determine whether Azure extension provisioning status is cleaner and reliable enough to replace the current Azure SSH marker wait while keeping learner deployment simple.

Related work: #100

[rishabkumar7]

@madebygps the azurerm_virtual_machine_extension has now been merged as part of #107 and all the work in #100

[rishabkumar7]

I am now exploring a clean way to implement AWS SSM.

[madebygps]

nice, you need to cut a release too whenever we have major functionality changes, cut one when you merge the AWS SSM thing please.