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

Add new resource region_instance_group_manager #394

Merged
merged 4 commits into from
Sep 9, 2017

Conversation

rosbo
Copy link
Contributor

@rosbo rosbo commented Sep 6, 2017

Fixes #45

I decided not to implement the client-side update_strategy like we did for the single zone instance_group_manager resource. The reason is that there is now a new rolling update feature in beta. I will add the beta update feature to both instance_group_manager and region_instance_group_manager in my next PR (see #51).

cc/ @paddycarver @selmanj

@rosbo rosbo changed the title Add new resource region_instance_group_manager. Add new resource region_instance_group_manager Sep 6, 2017
@rosbo rosbo requested a review from selmanj September 6, 2017 21:10
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.

Quick, minor feedback, and this should be good to go!

"target_pools": &schema.Schema{
Type: schema.TypeSet,
Optional: true,
DiffSuppressFunc: compareSelfLinkRelativePaths,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think DiffSuppressFunc works weirdly with Sets and Lists, IIRC. :/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed, the selfLinkRelativePathHash is enough since a target pool must be a self_link (API doesn't support name only). I added tests to make sure we don't regress on this. I will update the single zone resource in its own PR to do the same.

"health_check": &schema.Schema{
Type: schema.TypeString,
Required: true,
DiffSuppressFunc: compareSelfLinkRelativePaths,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think DiffSuppressFunc works weirdly with Sets and Lists, IIRC. :/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DiffSuppressFunc works well on nested string. At least we use it in many places and I just did some manual testing and works as expected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, my information must be out of date. :) Glad it works! I remember something about the count getting off or something, but it must have been fixed since then.

if err != nil {
if gerr, ok := err.(*googleapi.Error); ok && gerr.Code == 404 {
return false, nil
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like an error is being dropped here. What happens if it's not a 404?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't say for sure that the resource doesn't exist, it could be a transient error from the server side. I added a comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is totally undocumented and unclear, but in the case where an error is encountered checking for existence, Exists should return true with the error.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(The idea being that false with the error would remove the resource from state, which is not what we want. true will have no impact except returning the error, AFAIK.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning true and the error now. I agree, it makes way more sense this way.

@rosbo
Copy link
Contributor Author

rosbo commented Sep 8, 2017

TF_ACC=1 go test ./google -v -run TestAccRegionInstanceGroupManager_update -timeout 120m
=== RUN   TestAccRegionInstanceGroupManager_update
--- PASS: TestAccRegionInstanceGroupManager_update (151.99s)
=== RUN   TestAccRegionInstanceGroupManager_updateLifecycle
--- PASS: TestAccRegionInstanceGroupManager_updateLifecycle (118.69s)
PASS
ok  	github.com/terraform-providers/terraform-provider-google/google	270.807s

TargetPools: convertStringSet(d.Get("target_pools").(*schema.Set)),
AutoHealingPolicies: expandAutoHealingPolicies(d.Get("auto_healing_policies").([]interface{})),
// Force send TargetSize to allow size of 0.
ForceSendFields: []string{"TargetSize"},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TargetSize is Optional, and has no default. So if users don't set it, that will create a group with target size of 0 by default. Is that what we want? (I don't have a preference either way, just want to ask the question and get the answer recorded for posterity :D)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TargetSize of zero is the default behavior for our single zone resource: resource_compute_instance_group_manager. If user don't specify, I think it is better if we play it safe and don't create an arbitrary number of instances that our users might not want.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds sane and reasonable and like the best choice.

return err
}
managerV1.ForceSendFields = manager.ForceSendFields
op, err = config.clientCompute.RegionInstanceGroupManagers.Insert(project, d.Get("region").(string), managerV1).Do()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to future-Paddy:

I thought about asking to use getRegion here, but region is required, and it seems reasonable to require the user to specify which region they want their regional resource in, instead of just defaulting to the Provider-configured region.

return fmt.Errorf("Error creating RegionInstanceGroupManager: %s", err)
}

d.SetId(manager.Name)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we hypothetically have two IGMs in different regions with the same name? What if we use the "canonical link" that @selmanj used for #378?

Copy link
Contributor Author

@rosbo rosbo Sep 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name is unique globally. FYI: I was the one who actually wrote #378 ;)

I am working on a RegionalId and ZonalId class to standardize all of this. I left it to simply the name for now to mimic the behavior of the single zone resource (resource_compute_instance_group_manager). Once I am done with the reusable id classes, I will change all our resources to have consistent and more user-friendly import behavior.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name is unique globally.

Then ignore me entirely. :D

FYI: I was the one who actually wrote #378 ;)

Well, this is mortifying. Apologies. :(

I am working on a RegionalId and ZonalId class to standardize all of this. I left it to simply the name for now to mimic the behavior of the single zone resource (resource_compute_instance_group_manager). Once I am done with the reusable id classes, I will change all our resources to have consistent and more user-friendly import behavior.

Sounds good to me!

@rosbo rosbo merged commit c751a32 into hashicorp:master Sep 9, 2017
@rosbo rosbo deleted the region_instance_manager branch September 9, 2017 00:02
negz pushed a commit to negz/terraform-provider-google that referenced this pull request Oct 17, 2017
chrisst pushed a commit to chrisst/terraform-provider-google that referenced this pull request Nov 9, 2018
luis-silva pushed a commit to luis-silva/terraform-provider-google that referenced this pull request May 21, 2019
@ghost
Copy link

ghost commented Mar 31, 2020

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 ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature Request: support regional google instance group managers
2 participants