-
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
[Terraform]: Start removing beta igm/rigm fields. #669
[Terraform]: Start removing beta igm/rigm fields. #669
Conversation
I am a robot that works on MagicModules PRs! I built this PR into one or more PRs on other repositories, and when those are closed, this PR will also be merged and closed. |
I am (still) a robot that works on MagicModules PRs! I just wanted to let you know that your changes (as of commit b84475f) have been included in your existing downstream PRs. |
I am (still) a robot that works on MagicModules PRs! I just wanted to let you know that your changes (as of commit e300035) have been included in your existing downstream PRs. |
a621ea1
to
b9bafab
Compare
I am (still) a robot that works on MagicModules PRs! I just wanted to let you know that your changes (as of commit ad9533c) have been included in your existing downstream PRs. |
@@ -215,7 +230,8 @@ func resourceComputeInstanceGroupManager() *schema.Resource { | |||
|
|||
<% if version.nil? || version == 'ga' -%> | |||
"rolling_update_policy": &schema.Schema{ | |||
Deprecated: "This field is in beta and will be removed from this provider. Use it in the the google-beta provider instead. See https://terraform.io/docs/providers/google/provider_versions.html for more details.", | |||
Removed: "This field is in beta. Use it in the the google-beta provider instead. See https://terraform.io/docs/providers/google/provider_versions.html for more details.", | |||
Computed: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, why do we need to set this to computed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Afaik I got the impression at least once that you needed to do that in some edge case while removing some fields to avoid a diff, and have done so on any removal I've done since. Do you think we shouldn't have it set? Imo it's mostly harmless and as far as I can recall can only help.
@@ -525,14 +535,21 @@ func resourceComputeInstanceGroupManagerRead(d *schema.ResourceData, meta interf | |||
update_strategy = "REPLACE" | |||
} | |||
d.Set("update_strategy", update_strategy.(string)) | |||
|
|||
// Terraform _really_ doesn't like removing lists. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean? Why not? What happens?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I ran into like 5 occurrences of this in the same day and was not very patient with it. I'll update the comment to be better.
We get a permadiffdiff on the .#
of a list from 0 =>
(empty-as-in-nil).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would a state migration fix this? I think if we just run a state migration to remove that field entirely, that's.... safer in the long run, I believe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a state migration would work because this happens on new resources. The GKE CI tests failing the last few days were the same issue, fixed by #922
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's... concerning. If a field is marked as removed, it shouldn't wind up in state, I don't think? Let me verify that understanding really quick.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to verify: this permadiff happened when there were no d.Set
calls setting the field, right? The d.Set
was removed, the field was marked Removed, and then the tests were run, and they resulted in a permadiff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! This happens with TypeList
and TypeSet
s that we mark Removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very bizarre. Let me see if I can dig up some information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable to me. I'm chasing down details on why Removed
is awful, but let's not block on that, it's easy enough to delete code later.
I am (still) a robot that works on MagicModules PRs! I just wanted to let you know that your changes (as of commit 804da96) have been included in your existing downstream PRs. |
I am (still) a robot that works on MagicModules PRs! I just wanted to let you know that your changes (as of commit e5fd350) have been included in your existing downstream PRs. |
Oh wait I am still not sure what we want to do with It was never present at beta, and is only present at GA; it was previously used to turn on/off rolling updates, but they aren't present in GA anymore. That means that the user can set it to The way I see it, we can:
I'd like to do #3 because then it's done now instead of later, but I'm happy to do #2 because we remove the |
I think my original plan with it was to leave it, so we could add in REPLACE later... and then I found out REPLACE didn't make sense (IIRC) and forgot to go back and deprecate it... I think? I think I'd prefer option 2, because it doesn't hurt to just leave the field sitting around until 3.0.0 (I don't think), and we can deprecate it properly then. I know it's annoying to leave the schema there, but let's go ahead and deprecate it now, and we'll get it in the next round. Sorry for botching it this round. |
930abd6
to
5ca3e1f
Compare
OK, updated with #2 and then fixed tests. The only notable bit is that |
I am (still) a robot that works on MagicModules PRs! I just wanted to let you know that your changes (as of commit 26140ce) have been included in your existing downstream PRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked, and I think hardcoding to nil
will be a noop in 0.12, not an error, which is what I was worried about. I'll still check when the 0.12 SDK is finalized, but I think we're fine to take that approach for now.
…Computed, and ImportStateVerifyIgnore-ing update_strategy for rigm.
5ca3e1f
to
5f6dc4c
Compare
Hmm. I started on this resource thinking "I know [r]igm! This should be easy enough!" and I think I mostly got it right but
rigm.update_strategy
has bamboozled me - it doesn't do anything anymore but we forgot to deprecate it.Not looking for feedback until Monday, just writing this down so I can remember after I context switch.
Part of hashicorp/terraform-provider-google#1203
named_ports
to aSet
rolling_update_policy
,versions
,auto_healing_policies
from GA provider[all]
[terraform]
Start removing beta igm/rigm fields.
[terraform-beta]
[ansible]
[inspec]