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_kusto_database_principal Provider produced inconsistent result after apply when using Azure Function #7383

Closed
szaroubi opened this issue Jun 17, 2020 · 5 comments · Fixed by #7484

Comments

@szaroubi
Copy link
Contributor

Community Note

  • 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

Terraform (and AzureRM Provider) Version

Terraform v0.12.24
+ provider.azurerm v2.14.0

Your version of Terraform is out of date! The latest version
is 0.12.26. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

  • azurerm_kusto_database_principal

Terraform Configuration Files

provider "azurerm" {
  version = "=2.14.0"
  features {}
  skip_provider_registration = true
}


variable "rg" {
  type    = string
  default = "rg_axceta"
}

variable "loc" {
  type    = string
  default = "Canada Central"
}

variable "uniquePrefix" {
  default = "bugfortf"
}

variable "second_run" {
    type = number
    default = 0
}

resource "azurerm_kusto_cluster" "cluster" {
  name                = "${var.uniquePrefix}kustocluster"
  location            = var.loc
  resource_group_name = var.rg

  tags = {
    environment = "tf_bug_report"
  }
  sku {
    name     = "Dev(No SLA)_Standard_D11_v2"
    capacity = 1
  }
}

resource "azurerm_kusto_database" "database" {
  name                = "my-kusto-database"
  location            = var.loc
  resource_group_name = var.rg
  cluster_name        = azurerm_kusto_cluster.cluster.name

  hot_cache_period   = "P1D"
  soft_delete_period = "P1D"
}


resource "azurerm_storage_account" "example" {
  name                     = "${var.uniquePrefix}function"
  location                 = var.loc
  resource_group_name      = var.rg
  account_tier             = "Standard"
  account_replication_type = "LRS"

  tags = {
    environment = "tf_bug_report"
  }
}

resource "azurerm_app_service_plan" "example" {
  name                = "${var.uniquePrefix}-service-plan"
  location            = var.loc
  resource_group_name = var.rg

  kind     = "Linux"
  reserved = true

  sku {
    tier = "Basic"
    size = "B1"
  }
  tags = {
    environment = "tf_bug_report"
  }

}

resource "azurerm_function_app" "example" {
  name                = "${var.uniquePrefix}test-azure-functions"
  location            = var.loc
  resource_group_name = var.rg
  app_service_plan_id = azurerm_app_service_plan.example.id

  storage_account_name       = azurerm_storage_account.example.name
  storage_account_access_key = azurerm_storage_account.example.primary_access_key

  identity {
    type = "SystemAssigned"
  }

  tags = {
    environment = "tf_bug_report"
  }

  os_type = "linux"
}


resource "azurerm_kusto_database_principal" "principal" {
  resource_group_name = var.rg
  cluster_name        = azurerm_kusto_cluster.cluster.name
  database_name       = azurerm_kusto_database.database.name
  count = var.second_run
  role      = "Viewer"
  type      = "App"
  client_id = azurerm_function_app.example.identity[0].tenant_id
  object_id = azurerm_function_app.example.identity[0].principal_id
}

Expected Behavior

The Database Principal should be created for the Azure function

Actual Behavior

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_kusto_database_principal.principal[0]: Creating...

Error: Provider produced inconsistent result after apply

When applying changes to azurerm_kusto_database_principal.principal[0],
provider "registry.terraform.io/-/azurerm" produced an unexpected new value
for was present, but now absent.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Steps to Reproduce

  1. terraform apply
  2. terraform apply -var="second_run=1"

Step 2 is due to the fact the the Azure Function needs to be created before it is added to Kusto

Important Factoids

If this is not a priority and you can easily explain how to fix this, I will be happy to try my luck at it

@szaroubi
Copy link
Contributor Author

Just upgraded terraform to the latest (2.16) and issue still present,

$> terraform -v
Terraform v0.12.26
+ provider.azurerm v2.14.0

@oising
Copy link

oising commented Jun 17, 2020

So @szaroubi and I worked it out. The docs are wrong, and Microsoft probably aren't making it any easier for you guys (their ARM template refers to the client_id as the principalId which I would expect to be the objectId!). The correct incantation for adding an App is this:

# add a service pricinipal (azure app registration) as an APP
# these are the values from the app registration:
# tenant: TENANT_ID
# client/app: CLIENT_ID  (aka application id)
# objectid: OBJECT_ID

resource "azurerm_kusto_database_principal" "principal" {
  resource_group_name = "myresourcegroup"
  cluster_name        = "mykustoadx"
  database_name       = "mydb"
  role      = "Viewer"
  type      = "App"
  client_id = "TENANT_ID"
  object_id = "CLIENT_ID"
}

As you can see, the client_id wants the tenant ID, and the object_id wants the client ID, and the real app's object_id is not used at all. Clearly this is not correct/intuitive/sane.

@neil-yechenwei
Copy link
Contributor

Seems the example of the doc also points out it.

@oising
Copy link

oising commented Jun 18, 2020

Seems the example of the doc also points out it.

True, but any sane person will assume that's a typo or be entirely blind to it. It's quite natural to want to match client_id to client_id - this is intellisense in a nutshell.

@ghost
Copy link

ghost commented Aug 8, 2020

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!

@ghost ghost locked and limited conversation to collaborators Aug 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants