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

Support Spot VMs #10309

Closed
balboah opened this issue Oct 13, 2021 · 11 comments
Closed

Support Spot VMs #10309

balboah opened this issue Oct 13, 2021 · 11 comments

Comments

@balboah
Copy link

balboah commented Oct 13, 2021

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

I'm using preemtible instances today together with GKE autoscaling.
Just received the announcement from Google Cloud that they are switching to "Spot VMs".

I believe this feature should be added in the beta provider until GA.

New or Affected Resource(s)

  • google_container_node_pool
  • google_compute_instance

Potential Terraform Configuration

resource "google_container_node_pool" "primary_spotvm_nodes" {
  # ...

  node_config {
    spot  = true
    # ...
  }
}

References

@matthew-muscat
Copy link

Suggest that the potential terraform configuration for the instance is housed within the scheduling block (similar to where the preemptiable flag is)

resource "google_compute_instance" "instance" {
  name = "instance"
  #...

  scheduling {
    provisioning_model = SPOT
  }
}

Docs from gcloud beta cli...

 --provisioning-model=PROVISIONING_MODEL
    Specifies provisioning model, which determines price, obtainability,
    and runtime for the VM instance. PROVISIONING_MODEL must be (currently
    only one value is supported):

     SPOT
        Spot VM instances are preemptible VM instances without a 24-hour
        limit. They typically cost much less than a default VM, but have no
        guaranteed runtime.

@michal-kaciuba
Copy link

Hi, any estimate on release date for this feature?

@scotte
Copy link

scotte commented Dec 8, 2021

Hi, any estimate on release date for this feature?

@MKaciuba It's available now in the "google-beta" provider. I used it yesterday. Since Google considers spot instances to be preview status, perhaps Terraform won't release it to the "google" provider until Google considers it GA? Just speculation, I have no idea...

@azmng
Copy link

azmng commented Dec 13, 2021

Hi, any news regarding GCE support? I mean google_compute_instance and google_compute_instance_template resources, is there any plans to implement spot vms support?

@ShaunHowell
Copy link

Hi, the provisioning_model field is in the docs under beta but isn't actually included in the 4.11.0 release (link). It looks like this commit reverted its inclusion.
Was this an accident? Will this be re-included soon?

@lbg-raghu-vennam
Copy link

I just tried provisioning a spot instance and it worked with 4.13.0 provider version.

@rileykarson
Copy link
Collaborator

I'm not sure why this would have been in the [email protected], as it was in the release notes for https://github.com/hashicorp/terraform-provider-google-beta/releases/tag/v4.12.0. There may have been a minor hiccup- sorry about that!

I believe this issue is ready to be closed based on GoogleCloudPlatform/magic-modules#5662. @shuyama1 or @andrewyz please correct me if you feel otherwise! I see the PR says "part of" rather than "closes" which generally means a change only partially addresses an issue, but that's an unspoken meaning and I can't spot anything missing.

@andrewyz
Copy link

andrewyz commented Mar 15, 2022

There were some test failures in 4.11.0 (We started the release process and the API is changed after then, which causes some tests to fail). And then we submit a patch to fix it but can't catch up the time. So the commit was reverted and then released in 4.12.0. Not sure why the [email protected] didn't reflect this change.

@rileykarson
Copy link
Collaborator

Hmm- the docs appear to have been properly reverted (we've reverted the code and not the docs in the past, so I figured I'd check that!). @megan07 is there a way to check the registry's commit/tag for past versions? This probably isn't worth spending much time on since it's correct in latest, but I'm curious 🤷

@andrewyz can you confirm that we can close this issue now?

@andrewyz
Copy link

andrewyz commented Mar 15, 2022

Yes, looks good so far.

@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants