hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.6k stars 4.64k forks source link

Timeout for Azure SQL managed instance #14789

Open AkhilaMadduri opened 2 years ago

AkhilaMadduri commented 2 years ago

Terraform (and AzureRM Provider) Version

2.90.0

Affected Resource(s)

azurerm_sql_managed_instance

Output

module.sql_managed_instance.azurerm_sql_managed_instance.sql_managed_instance: Still modifying... [id=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-...sql-instance, 32m2s elapsed] module.sql_managed_instance.azurerm_sql_managed_instance.sql_managed_instance: Still modifying... [id=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-...sql-instance, 32m12s elapsed]

Error: Code="OperationTimedOut" Message="The operation timed out and automatically rolled back. Please retry the operation."

with module.sql_managed_instance.azurerm_sql_managed_instance.sql_managed_instance, on modules\sql_managed_instance\main.tf line 7, in resource "azurerm_sql_managed_instance" "sql_managed_instance": 7: resource "azurerm_sql_managed_instance" "sql_managed_instance" {

Expected Behaviour

Shouldn't expect the timeout error.

Actual Behaviour

Though we make small changes in the code it's taking 32min12sec to run the script and after that time it's throwing an error that the operation timed out and automatically rolled back. This is even happening after changing the timeout of update to 8hrs.

mybayern1974 commented 2 years ago

@AkhilaMadduri , thank you for opening this issue. Could you please provide your terraform config that could help repro and troubleshooting?

drazkiewicz commented 2 years ago

Same issue here. Simple change of SKU. Basic terraform configuration for SQL MI.

Additionally once destroying SQL MI this error came out: image

binuverghese commented 2 years ago

Any solution for statuscode=200 issue? Please advise, I'm facing the same issue

robertoandrade commented 1 year ago

Having a similar issue provisioning a azurerm_mssql_server resource, after ~30min it times out and I get the same exact message. Funny enough the although we get an error response from the API the server does not get rolled back and goes on to be properly provisioned after another while.

I suppose this isn't defined by the standard terraform "timeout" settings one can set on a per resource basis right? since that controls more the time of the polling of the API client?

TinaET commented 1 year ago

Having a similar issue provisioning a azurerm_mssql_server resource, after ~30min it times out and I get the same exact message. Funny enough the although we get an error response from the API the server does not get rolled back and goes on to be properly provisioned after another while.

I suppose this isn't defined by the standard terraform "timeout" settings one can set on a per resource basis right? since that controls more the time of the polling of the API client?

Hi @robertoandrade , I got the same error when creating azurerm_mssql_server, I can run terraform apply successfully in my local pc, but always get 30 mins timeout in pipeline, did you find any solution for this issue?

ADBjester commented 1 year ago

It is really quite simple, assuming you're using an Azure YAML pipeline with stages to plan and apply.

  # Apply 
  - stage: terraform_apply_${{ parameters.deploymentEnvironment }}_${{ parameters.deploymentRegion }}
    displayName: 'Terraform Apply - ${{ parameters.deploymentEnvironment }} - ${{ parameters.deploymentRegion }}'
    variables:
      terraformWorkspace: '${{ parameters.deploymentEnvironment }}_${{ parameters.deploymentRegion }}'
parameters.deploymentRegion }}) ] #'${{ parameters.deploymentEnvironment }}_${{ parameters.deploymentRegion }}'
    jobs:
      - deployment: 'terraform_apply_${{ parameters.deploymentEnvironment }}_${{ parameters.deploymentRegion }}'
        timeoutInMinutes: 420
        environment: '${{ parameters.approvalEnvironment }}'

I added the "timeoutInMinutes" line to the apply stage of our pipeline, and checked it in as a branch to our pipelines called "feature/extended-timeout". Anything that needs to deploy a new managed instance uses this branch (which will now run to completion, still taking the expected 3-5 hours to instantiate the managed instance), while shorter-lived things that ought timeout quicker use the master branch.

YMMV. Good luck!

Jeff Woods Azure Architect Oaks, PA

ADBjester commented 1 year ago

@kpggt SQL Managed instance is an exception. Deployments of SQL MI do take hours, even using ARM or Portal. It is documented as such.

https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/instance-pools-configure?view=azuresql&tabs=powershell

So, your options are to let the pipeline timeout, and then run it a second time to finish the rest.... or to extend the timeout for those very first initial deployments, where the instance pool is being created.

Subsequent runs that alter the managed instance won't take nearly so long, as long as you don't change the underlying hardware class underneath. You can add storage space, change the number of cores (within the same hardware class), etc, in minutes. But to deploy a brand new managed instance, or move it to different hardware, requires the lengthy creation of the instance pool.

kpggt commented 1 year ago

My apologies i didn't see / realize it was a post regarding managed instances. I don't use them