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

azurerm_cognitive_deployment tries to update version, but doesn't really do so #24516

Closed
1 task done
XDanny322 opened this issue Jan 17, 2024 · 2 comments · Fixed by #24700
Closed
1 task done

azurerm_cognitive_deployment tries to update version, but doesn't really do so #24516

XDanny322 opened this issue Jan 17, 2024 · 2 comments · Fixed by #24700

Comments

@XDanny322
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Community Note

Hi -

There seems to be an issue with the azurerm_cognitive_account resource, but i can't pin down what / why, or if im just doing something wonkey.

Whats seems to be happening is, when i update just a "deployment's" version, terraform states it tried, and successful done so, but when i look on the azure OpenAI Studio portal, the old verion is still there.

if i rerun TF, TF will try again to update the versino, success, but again, nothing done.

Just for completeness sake, if i edit the version within the OpenAI Studio portal, the change sticks, that the new version stays.

For example, this terraform code will create an OpanAI account (Open AI instance in azure), and also a deplyment of gpt4.

provider "azurerm" {
  features {}
}

variable "project_name" { default = "dlaitest1" }
variable "resource_group_name" { default = "xxx" }
variable "region" { default = "eastus" }

## Creates the OpenAI instance
resource "azurerm_cognitive_account" "example" {
  name                = var.project_name
  location            = var.region
  resource_group_name = var.resource_group_name
  kind                = "OpenAI"

  sku_name = "S0"

  tags = {
    Acceptance = "Test"
  }
}

resource "azurerm_cognitive_deployment" "example" {
  name                 = "${var.project_name}-deployment"
  cognitive_account_id = azurerm_cognitive_account.example.id

  version_upgrade_option = "NoAutoUpgrade"
  model {
    format = "OpenAI"

    name    = "gpt-4"
    # version = "0613"
    version = "0314"
  }

  scale {
    type     = "Standard"
    capacity = 1
  }
}

Run terraform apply, and all will work well.

Then if we switch the version, more specifcally, just switch the version number from version = "0314" to version = "0613" and run TF apply, TF will success:

(.venv) ☁  cognitiveservices [main] ⚡  terraform apply --auto-approve 
azurerm_cognitive_account.example: Refreshing state... [id=/subscriptions/<my_sub_id>/resourceGroups/<my_resource_group>/providers/Microsoft.CognitiveServices/accounts/dlaitest1]
azurerm_cognitive_deployment.example: Refreshing state... [id=/subscriptions/<my_sub_id>/resourceGroups/<my_resource_group>/providers/Microsoft.CognitiveServices/accounts/dlaitest1/deployments/dlaitest1-deployment]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
  ~ update in-place

Terraform will perform the following actions:

  # azurerm_cognitive_deployment.example will be updated in-place
  ~ resource "azurerm_cognitive_deployment" "example" {
        id                     = "/subscriptions/<my_sub_id>/resourceGroups/<my_resource_group>/providers/Microsoft.CognitiveServices/accounts/dlaitest1/deployments/dlaitest1-deployment"
        name                   = "dlaitest1-deployment"
        # (2 unchanged attributes hidden)

      ~ model {
            name    = "gpt-4"
          ~ version = "0613" -> "0314"
            # (1 unchanged attribute hidden)
        }

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
azurerm_cognitive_deployment.example: Modifying... [id=/subscriptions/<my_sub_id>/resourceGroups/<my_resource_group>/providers/Microsoft.CognitiveServices/accounts/dlaitest1/deployments/dlaitest1-deployment]
azurerm_cognitive_deployment.example: Still modifying... [id=/subscriptions/24523695-c7d5-44c4-af22-...test1/deployments/dlaitest1-deployment, 10s elapsed]
azurerm_cognitive_deployment.example: Modifications complete after 12s [id=/subscriptions/<my_sub_id>/resourceGroups/<my_resource_group>/providers/Microsoft.CognitiveServices/accounts/dlaitest1/deployments/dlaitest1-deployment]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

... be nothing really changed ...

My current workaround is force a delete / recreate using replace_triggered_by, locals, and null_resource to force recreation of the deployment, which causes downtime.

provider "azurerm" {
  features {}
}

variable "project_name" { default = "dlaitest1" }
variable "resource_group_name" { default = "xxxxx" }
variable "region" { default = "eastus" }

## Creates the OpenAI instance
resource "azurerm_cognitive_account" "example" {
  name                = var.project_name
  location            = var.region
  resource_group_name = var.resource_group_name
  kind                = "OpenAI"

  sku_name = "S0"

  tags = {
    Acceptance = "Test"
  }
}

## Var for the version
locals {
  version = "0314"
  # version = "0613"
}

# null resource to trigger the recreation of the entire deployment, since
# it looks like terraform doesn't work when trying to update just the version number;
# e.g. TF will plan/apply and tell you it did the work, but in reality, it did not.
resource "null_resource" "example" {
  triggers = {
    version = local.version
  }
}


resource "azurerm_cognitive_deployment" "example" {
  name                 = "${var.project_name}-deployment"
  cognitive_account_id = azurerm_cognitive_account.example.id

  version_upgrade_option = "NoAutoUpgrade"
  model {
    format = "OpenAI"

    name = "gpt-4"
    # version = "0613"
    # version = "0314"
    version = local.version
  }

  scale {
    type     = "Standard"
    capacity = 1
  }
  lifecycle {
    replace_triggered_by = [
      # See null_resource.example for when we need to do this.
      null_resource.example
    ]
  }
}
  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.6.6 (Also tried 1.5.4)

AzureRM Provider Version

v3.87.0 (Also tried a few version between 3.87.0 to v3.80.0)

Affected Resource(s)/Data Source(s)

azurerm_cognitive_deployment

Terraform Configuration Files

See Body

Debug Output/Panic Output

See Body

Expected Behaviour

I expect the version number to be updated in place, similar to how it was successful when using the console.

Actual Behaviour

Terraform run is success, the the change to the version number never really happened.

Steps to Reproduce

  1. Create main.tf
  2. paste the code from the body of the message into it
  3. Auth against azure
  4. Update the resource group to an existing resource group
  5. run terraform apply

Important Factoids

No response

References

No response

@liuwuliuyun
Copy link
Contributor

liuwuliuyun commented Jan 17, 2024

Hi @XDanny322, thanks for raising this issue. I tested in my local and reproduced what you described. This could be a bug in AzureRM provider. I will raise a PR shortly to address this issue.

@XDanny322 XDanny322 changed the title azurerm_cognitive_account tries to update version, but doesn't really do so azurerm_cognitive_deployment tries to update version, but doesn't really do so Jan 17, 2024
@rcskosir rcskosir added the bug label Jan 17, 2024
Copy link

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.