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

Groundwork for Custom Timeouts #4475

Merged
merged 7 commits into from
Oct 4, 2019
Merged

Groundwork for Custom Timeouts #4475

merged 7 commits into from
Oct 4, 2019

Conversation

tombuildsstuff
Copy link
Contributor

@tombuildsstuff tombuildsstuff commented Oct 1, 2019

This PR contains the necessary groundwork to support Custom Timeouts on both Resources and Data Sources

Whilst this functionality is controlled by a feature toggle (which is intentionally disabled by default) - in it's current form this functionality has no effect on existing resources, therefore it's intentionally not documented or recommended for use at this time.

When the context changes have been threaded through all of the resources, in a future 1.x release we'll document this behaviour so that users can opt into this - however at this time this functionality is unsupported.

Given this is feature toggled we should be able to add timeouts gradually to resources, internally if the feature toggle is disabled any timeouts defined on resources will be removed, leading to the same behaviour as today - for example:

Given the following configuration:

$ cat main.tf
resource "azurerm_resource_group" "test" {
  name = "tom-dev6666"
  location = "West Europe"

  timeouts {
    create = "2s"
    delete = "4s"
  }
}

Without the feature enabled:

$ terraform apply

Error: Unsupported block type

  on main.tf line 5, in resource "azurerm_resource_group" "test":
   5:   timeouts {

Blocks of type "timeouts" are not expected here.

With the feature enabled:

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # azurerm_resource_group.test will be created
  + resource "azurerm_resource_group" "test" {
      + id       = (known after apply)
      + location = "westeurope"
      + name     = "tom-dev6666"
      + tags     = (known after apply)

      + timeouts {
          + create = "2s"
          + delete = "4s"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

azurerm_resource_group.test: Creating...

Error: Error creating resource group: resources.GroupsClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

(this obviously works with a more sane timeout configured, 2s/4s are an example)

The (acceptance) test suite itself intentionally doesn't configure any timeouts in the Check Func's since we should continue polling until we have a conclusion

Longer term this unblocks #171 (and related issues like #1747) which forms a part of #2807

@tombuildsstuff tombuildsstuff added this to the v1.36.0 milestone Oct 1, 2019
@tombuildsstuff tombuildsstuff requested a review from katbyte October 1, 2019 14:52
@ghost ghost added the size/L label Oct 1, 2019
Copy link
Collaborator

@katbyte katbyte left a comment

Choose a reason for hiding this comment

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

Looks great! 🚀

@tombuildsstuff
Copy link
Contributor Author

Looks like some issues between Travis <-> Github - it's green in Travis:

Screenshot 2019-10-02 at 07 55 03

@tombuildsstuff tombuildsstuff merged commit d413ab8 into master Oct 4, 2019
@tombuildsstuff tombuildsstuff deleted the f/custom-timeouts branch October 4, 2019 10:32
tombuildsstuff added a commit that referenced this pull request Oct 4, 2019
@ghost
Copy link

ghost commented Oct 29, 2019

This has been released in version 1.36.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 1.36.0"
}
# ... other configuration ...

@ghost
Copy link

ghost commented Nov 3, 2019

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 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants