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

Rolling update support for instance group manager #1137

Merged

Conversation

ishashchuk
Copy link
Contributor

@ishashchuk ishashchuk commented Feb 28, 2018

Addresses 51

Supports beta functionality for rolling updates.

When rolling_update is selected as update_strategy, it requires "rolling_update_policy" block.
I'm storing rolling_update_policy block locally, and not applying it to computeBeta.InstanceGroupManager. There is no way to make an update call for this block on the InstanceGroupManager. It is only updated when the patch call for the instances is made. That's the reason I'm storing it locally and only applying it on the update calls that are changing the instance template. That allows us to change rolling_update_policy arguments post creating InstanceGroupManager and making sure that they will be applied at the next patch call.

Once I get feedback on this, I will add similar support to region_instance_group_manager

@apenney
Copy link

apenney commented Mar 1, 2018

@ishashchuk I don't have any code feedback, I just wanted to thank you for tackling this (as we'll be early adopters of it, soon as it's merged).

@amoiseiev
Copy link

@paddycarver friendly reminder :)

@nat-henderson nat-henderson self-requested a review March 12, 2018 21:37
Copy link
Contributor

@nat-henderson nat-henderson left a comment

Choose a reason for hiding this comment

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

I'm storing rolling_update_policy block locally, and not applying it to computeBeta.InstanceGroupManager. There is no way to make an update call for this block on the InstanceGroupManager. It is only updated when the patch call for the instances is made. That's the reason I'm storing it locally and only applying it on the update calls that are changing the instance template.

I like this... but I wonder, what happens if someone:

  • creates the resource with RESTART
  • changes it to ROLLING_UPDATE
  • does an update
  • changes it back to RESTART
  • does another update

In that case, would this code act correctly? It seems like it wouldn't send a PATCH request to remove the strategy, but I might be off.

@@ -184,6 +241,12 @@ func resourceComputeInstanceGroupManagerCreate(d *schema.ResourceData, meta inte
return err
}

_, ok := d.GetOk("rolling_update_policy")
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Seems like it'd be neater as part of the if block below.

@@ -380,6 +443,11 @@ func resourceComputeInstanceGroupManagerUpdate(d *schema.ResourceData, meta inte

d.Partial(true)

_, ok := d.GetOk("rolling_update_policy")
Copy link
Contributor

Choose a reason for hiding this comment

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

same comment - include in the if statement if possible.

@ishashchuk
Copy link
Contributor Author

I like this... but I wonder, what happens if someone:

  • creates the resource with RESTART
  • changes it to ROLLING_UPDATE
  • does an update
  • changes it back to RESTART
  • does another update

In that case, would this code act correctly? It seems like it wouldn't send a PATCH request to remove the strategy, but I might be off.

@ndmckinley
There is no need to remove the strategy, since it only matters on PATCH requests. PATCH request is using a different API endpoint(clientComputeBeta.InstanceGroupManagers.Patch) and is only used when the resource is set to ROLLING_UPDATE. And we will always get the most up-to-date strategy from the config, because we are passing it explicitly on template change

When resource is set to RESTART, config.clientCompute.InstanceGroupManagers.RecreateInstances is used and that endpoint doesn't care about update_strategy attributes. It reboots all the machines at the same time.

@nat-henderson
Copy link
Contributor

Ah! That's quite nice, then, neat trick. I think (but am not 100% sure) that I'd like it to be set during Create as well as during Update, then, because in the event that someone creates a resource with Terraform then runs a ROLLING_UPDATE manually or using some other tool, I think the most sensible behavior is to default to what they specified in Terraform. Does that seem right to you?

@ishashchuk
Copy link
Contributor Author

ishashchuk commented Mar 14, 2018

@ndmckinley
I don't think there is much value in setting update_strategy on CREATE, because most of the tools are either expect the user to provide those values, or use their own defaults.

In UI, the values for ROLLING RESTART/REPLACE are pre-populated with defaults, which means that the values instantiated on terraform create won't be respected

Running gcloud beta compute instance-groups managed rolling-action without specifying strategy, use their own defaults too without respecting anything that was previously set on instance manager

@nat-henderson
Copy link
Contributor

Fair enough - can you add a comment to that effect? Just that and I'll be ready to merge.

@ishashchuk
Copy link
Contributor Author

Should be good to go

@nat-henderson
Copy link
Contributor

Perfect. I'm running the tests now, and I expect to merge in an hour or so assuming no problems.

@nat-henderson nat-henderson merged commit 14f1431 into hashicorp:master Mar 15, 2018
ashish-amarnath pushed a commit to ashish-amarnath/terraform-provider-google that referenced this pull request Mar 20, 2018
@ishashchuk ishashchuk deleted the ishashchuk_rollingRestarts branch March 21, 2018 18:33
chrisst pushed a commit to chrisst/terraform-provider-google that referenced this pull request Nov 9, 2018
@ghost
Copy link

ghost commented Nov 19, 2018

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 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators Nov 19, 2018
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.

5 participants