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

[Terraform]: Start removing beta igm/rigm fields. #669

Merged

Conversation

rileykarson
Copy link
Member

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

  • Change named_ports to a Set
  • Remove rolling_update_policy, versions, auto_healing_policies from GA provider
  • Remove old self link stability test

[all]

[terraform]

Start removing beta igm/rigm fields.

[terraform-beta]

[ansible]

[inspec]

@modular-magician
Copy link
Collaborator

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.
depends: hashicorp/terraform-provider-google-beta#76
depends: hashicorp/terraform-provider-google#2393

@modular-magician
Copy link
Collaborator

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.

@rileykarson rileykarson changed the title [Terraform]: [WIP] Start removing beta igm/rigm fields. [Terraform]: Start removing beta igm/rigm fields. Nov 7, 2018
@modular-magician
Copy link
Collaborator

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.

@modular-magician
Copy link
Collaborator

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,
Copy link
Contributor

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?

Copy link
Member Author

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.
Copy link
Contributor

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?

Copy link
Member Author

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).

Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Member Author

@rileykarson rileykarson Nov 19, 2018

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 TypeSets that we mark Removed.

Copy link
Contributor

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.

Copy link
Contributor

@paddycarver paddycarver left a 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.

@modular-magician
Copy link
Collaborator

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.

@modular-magician
Copy link
Collaborator

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.

@rileykarson
Copy link
Member Author

Oh wait I am still not sure what we want to do with update_strategy in GA rigm.

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 NONE or... well, NONE is the only value now. It's a useless field.

The way I see it, we can:

  • Add the Terraform-driven update stuff from igm which we will then need to deprecate and remove in 3.0.0 once real updates go GA
  • Deprecate the field now and remove in 3.0.0. It won't do anything and any code interacting with it can be removed.
  • Remove the field now and woops we missed the deprecation on that one. But the field is useless so it isn't that bad.

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 Read code regardless.

@paddycarver
Copy link
Contributor

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.

@rileykarson
Copy link
Member Author

OK, updated with #2 and then fixed tests.

The only notable bit is that update_policy was causing diffs in our released 1.19.0, not sure why CI didn't catch that before but it did yesterday. Marked it Computed to fix that.

@modular-magician
Copy link
Collaborator

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.

Copy link
Contributor

@paddycarver paddycarver left a 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.

@modular-magician modular-magician merged commit 9d19ec3 into GoogleCloudPlatform:master Nov 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants