canIpForward field is missing from terraform created template #5285
Assignees
Labels
Comments
|
@jsoref I see |
|
@edwardmedia: I don't see why this would be a bug in Beyond that, I'm not a I fully expect a
|
|
@danawillow: Could you please bring this to the gcloud folks? |
|
@jsoref, if you run We can certainly talk to the gcloud team, but I'd like to know your use case first so the team can accurately assess the priority of the request. |
|
Yes, So, no, it doesn't appear that the property is included. Which makes this the opposite of #5295 where the interface is forcibly included and can't be omitted. |
|
I have one more bug to file in these fun adventures... |
|
Cool, the last one is unrelated to this specific issue so it should be filed separately. I'd like to repeat my question about your use case. It would be helpful to know what you expect and why so we can try to solve your issue in the best way possible. My guess is that gcloud just doesn't show default values if they weren't set explicitly, which seems reasonable. |
|
Generally, I expect to have the same behavior as I get from using Since the templates I created using those (I'm not sure which of the two) included the I'm trying to migrate from manually created things to terraform managed things, but if I can't produce something that's fairly identical, I don't have much faith that my replacements are equivalent. I made the mistake of changing the |
|
Note: if I explicitly set something in terraform, I expect it to be persisted. If I don't set it, my preference is for it not to be persisted. Between how terraform handles this field and how it handles the |
|
In case you find it interesting (@edwardmedia you probably will!), here's some context as to what's going on and why. There are three different places that this field gets handled:
The thing that makes this field interesting is that it's set to the server-side default value, which also happens to be the zero value in go (false, since it's a boolean). So let's start with what happens provider-side. We have three options for how to read the values that are set in the config: Next up, let's talk about what happens in the client libraries. If a field with a zero value is set on a field, it by default does not get included in the request that is sent to server. If we want to send it explicitly, we have to set something called Last, we can talk about what happens when you run If we wanted to make it so that gcloud explicitly showed the value when set to I have a few recommendations of what you can do instead. One would be to recognize default values in your validation- if a default for a value is false, then recognizing that it being persisted as false and it being unset are the same. Secondly, consider using a testing framework for Terraform (https://github.com/gruntwork-io/terratest is one example and they list some others in their repo). Lastly, and in my opinion the most important, would be to test the behavior of the resources you create instead of only testing their values- does the instance template do what you need it to do? If so, then your config was probably right (this feels similar to the common testing best practice of testing behavior instead of implementation). Hope this helps! |
|
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
ghost
locked and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Community Note
Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
Panic Output
Expected Behavior
A similarly manually created template includes:
Actual Behavior
plan output:
describe output:
Steps to Reproduce
terraform applygcloud compute instance-templates describe nodeImportant Factoids
References
The text was updated successfully, but these errors were encountered: