-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Google compute instance recreate on disk resize #6087
Comments
Initialize_params are the parameters of a disk on creation, they’re a shorthand for actually creating a disk resource. So the only way to change the params a disk was created with is to actually recreate it (and therefore the instance). I tried the API and Cloud Console they didn't allow boot disk size property. Please let me know if it helps .. |
We use this without incident across many different instances. We can also increase this size without issue from api/ui. We shouldn't need to recreate an entire instance simply because we need to increase disk size. |
You can make changes to additional disks (increase its size) without recreating the instance, however you can't do that on boot disk. Boot_disk is for specific instance can't be shared, looks like what you are looking for is additional disk.
|
We use attached disks as well but there are instances when the boot disk needs to grow in size. Having to completely recreate the instance seems excessive when we can increase the disk size. |
Would you be able to increase the boot_disk size of an instance in gcloud or cloud console without stopping the instance ?. If so and terraform provider lacks that feature we can work on a feature request for that. |
Yes you can increase disk size without stopping the instance or destroying it from the gcp ui/gcloud cli/api |
With the current state of the provider code we can't resize the boot_disk(internal) without recreating the instance as we deal with only instance APIs for this resource. We may need to interact with Disk API directly for altering the size ( |
I understand that it may require an additional api call but changing the boot disk size should not cause a recreation of the instance. So i don't think this is appropriate for an RFE. Terraform documentation also refers to these initialization options in the default documentation. |
Hey @jdziat, this is one reason why we support the source parameter on the boot disk block. This way, you can create a disk in Terraform that can be updated whenever you want, and we can let Here's a sample config from our test suite:
If you aren't able to create a new resource at this time, I believe that importing the VM+disk should set the appropriate values in state such that you could seamlessly migrate to a config that looks like the one I posted, though I'd recommend trying it somewhere throwaway first before trying it on a real config. Do any of these ideas sound like something you could do? |
@danawillow I appreciate that it supports the source block, but that's not clear from the examples or documentation what the best practice should be in this case. I don't see the use case for having the initialization params as a locked in value. I may be biased though because I have a few hundred machines that could be impacted by this. |
How probable is that this is going to be implemented within the next few weeks, @danawillow ? I am asking because we are also affected by this issue on hundreds of machines and we would like to know if we should work around this limitation or wait for the fix. |
Not very likely. Our team still isn't quite convinced that we want to support updating something that's specifically meant to be for initialization. |
…ashicorp#6087) Signed-off-by: Modular Magician <magic-modules@google.com>
b/261963160 |
Boot disk resizes still not working with the GCP terraform ,its impacting number of VMS ,Terraform state file will be corrupted and it will block us to do any further changes. |
I'm going to add a +1 here as well, it feels strange that disk configurations like labels (literal metadata) and size can be updated in place without stopping or recreating anything if we use the API or console but there is no way to do it in Terraform. We are trying to add cost tracking labels to our infrastructure and there is no way to do so without hacking around outside of terraform. We will definitely not be recreating boot disks across dozens of kafka, postgres, and clickhouse data storage clusters to add a label as that seems ripe for causing an incident, not to mention a ton of work. Please consider:
|
I'd like to add another voice of support for what's been mentioned here previously. To have a label change try to recreate disks is unexpected, unintuitive, and quite frankly outright dangerous. Most of the examples you find online (officially and from blogs etc.) show the "embedded" variant of creating the boot disk, and don't prominently mention the potential issue of being unable to change it without recreating. I understand that the parameter has "initialise" in its name, so there's the semantic argument about it technically not being correctly used if someone wants to change something. It seems a bit like the provider has built a UX trap, and then blames the user for falling into it. I strongly urge to consider rethinking this behaviour and changing it to something that is more intuitive and less dangerous. @mwarkentin mentioned a few options that seem like they would be a good fit for a long-term solution. |
We ran into this issue and it caused an outage due to the fact that it cycled all the instances and caused production downtime because we'd manually worked around this, only for an out of date terraform run to cause all instances to be recreated. We're already moving off Google Cloud, but for the poor souls who happen to be stuck with y'all, I would implore you have a look at modifying this behavior; it's actively dangerous |
Save us from the stalebot: #17044 (comment) |
Community Note
modular-magician
user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned tohashibot
, a community member has claimed the issue already.Terraform Version
Terraform v0.11.14
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
Terraform should resize the boot disk
Actual Behavior
Terraform wants to recreate the instance to increase the size of the bootdisk
Steps to Reproduce
terraform plan
Important Factoids
References
b/321386804
The text was updated successfully, but these errors were encountered: