-
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
Add new resource region_instance_group_manager #394
Conversation
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.
Quick, minor feedback, and this should be good to go!
"target_pools": &schema.Schema{ | ||
Type: schema.TypeSet, | ||
Optional: true, | ||
DiffSuppressFunc: compareSelfLinkRelativePaths, |
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 think DiffSuppressFunc
works weirdly with Sets and Lists, IIRC. :/
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.
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, |
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 think DiffSuppressFunc
works weirdly with Sets and Lists, IIRC. :/
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.
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.
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.
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 | ||
} |
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 like an error is being dropped here. What happens if it's not a 404?
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.
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.
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.
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.
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.
(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.)
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.
Returning true and the error now. I agree, it makes way more sense this way.
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"}, |
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.
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)
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.
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.
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.
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() |
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.
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) |
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.
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.
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.
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.
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!
…ts (hashicorp#394) Signed-off-by: Modular Magician <[email protected]>
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! |
Fixes #45
I decided not to implement the client-side
update_strategy
like we did for the single zoneinstance_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 bothinstance_group_manager
andregion_instance_group_manager
in my next PR (see #51).cc/ @paddycarver @selmanj