terraform-provider-azurerm icon indicating copy to clipboard operation
terraform-provider-azurerm copied to clipboard

Cannot deploy Logic App when site_config is present in resource configuration

Open Jeffrey20241 opened this issue 9 months ago • 4 comments

Is there an existing issue for this?

  • [X] I have searched the existing issues

Community Note

  • Please vote on this issue by adding a :thumbsup: 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.8.2

AzureRM Provider Version

3.102.0

Affected Resource(s)/Data Source(s)

azurerm_logic_app_standard

Terraform Configuration Files

terraform {
  backend "local" {}
}

provider "azurerm" {
  features {}
  subscription_id            = ""
  tenant_id                  = ""
  skip_provider_registration = false  
}

resource "azurerm_storage_account" "storage_account" {
  name                     = "jqsa948436"
  resource_group_name      = "FA-TEST"
  location                 = "UKSouth"
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_storage_share" "storage_share" {
  name                 = "share001"
  storage_account_name = azurerm_storage_account.storage_account.name
  quota                = 50
}

resource "azurerm_service_plan" "service_plan" {
  name                         = "sp1"
  location                     = "UKSouth"
  os_type                      = "Windows"
  resource_group_name          = "FA-TEST"
  sku_name                     = "WS1"
  maximum_elastic_worker_count = 2
  worker_count                 = 2
}

resource "azurerm_logic_app_standard" "logic_app_standard" {
  name                       = "testjq1233"
  location                   = "UKSouth"
  resource_group_name        = "FA-TEST"
  app_service_plan_id        = azurerm_service_plan.service_plan.id
  storage_account_name       = azurerm_storage_account.storage_account.name
  storage_account_access_key = azurerm_storage_account.storage_account.primary_access_key
  storage_account_share_name = "share001"
  site_config {
    always_on                        = true
    runtime_scale_monitoring_enabled = true
  }
}

Debug Output/Panic Output

Error: creating Logic App Standard: (Site Name "testjq1233" / Resource Group "FA-TEST"): web.AppsClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property." Details=[{"Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property."},{"Code":"BadRequest"},{"ErrorEntity":{"Code":"BadRequest","ExtendedCode":"01020","Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property.","MessageTemplate":"There was a conflict. {0}","Parameters":["SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property."]}}]

Expected Behaviour

Logic App should be deployed with site_config configuration declared

Actual Behaviour

Deploying azurerm_logic_app_standard with any site_config produced error: SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property.

If you deploy azurerm_logic_app_standard without any site_config, then the deployment completes with issue; ie:

resource "azurerm_logic_app_standard" "logic_app_standard" {
  name                       = "testjq1233"
  location                   = "UKSouth"
  resource_group_name        = "FA-TEST"
  app_service_plan_id        = azurerm_service_plan.service_plan.id
  storage_account_name       = azurerm_storage_account.storage_account.name
  storage_account_access_key = azurerm_storage_account.storage_account.primary_access_key
  storage_account_share_name = "share001"
}

Tried rolling back to AzureRM 3.101.0 which deployed this Logic App without issue last week but also experiences this same issue.

Steps to Reproduce

Deploy as per 'Terraform Configuration Files' example, it will fail. Take out site_config from azurerm_logic_app_standard and it works fine

Important Factoids

No response

References

No response

Jeffrey20241 avatar May 07 '24 16:05 Jeffrey20241

Hi @Jeffrey20241, thanks for reporting.

It seems to be caused because the service behavior changed. Opened an issue on azure-rest-api-specs to bring this to the service team.

At the same time, to fix this on the Terraform AzureRM provider side, we will need to upgrade the API version and change our implementation. There is an exsiting PR for this kind issue link. Will dive into it and update here for any progress.

Thanks.

ziyeqf avatar May 09 '24 07:05 ziyeqf

@ziyeqf

At the same time, to fix this on the Terraform AzureRM provider side, we will need to upgrade the API version and change our implementation.

Yes, after digging into this issue I believe we need to update Logic Apps SDK in AzureRM globally. Is it in progress by someone? As we wanted to make that migration, so I do not want to make same work in parallel.

dkuzmenok avatar May 14 '24 08:05 dkuzmenok

Hi, Its a blocker issue for majority of the people as we not able to deploy Logic App at all, Can this be expedited please?

pritiyadav537 avatar May 14 '24 08:05 pritiyadav537

Are there any updates to this issue yet? This seems to be taking some time to resolve and is a complete blocker for us to deploy our Logic Apps. If I don't receive an update by the end of the day, I'm going to create a local-exec provisioner for the site config as a workaround, if it works well, I'll post the code here.

jobinsj27 avatar May 14 '24 12:05 jobinsj27

@ziyeqf

At the same time, to fix this on the Terraform AzureRM provider side, we will need to upgrade the API version and change our implementation.

Yes, after digging into this issue I believe we need to update Logic Apps SDK in AzureRM globally. Is it in progress by someone? As we wanted to make that migration, so I do not want to make same work in parallel.

Per discussion with the service team, the service should work with the current Terraform provider version. For migration to newer version, per my understanding, these resources should be swapped to go-azure-sdk first, then it will be able to be upgraded to newer API version. I may recommend to hold on, we are in discussion with the service team and will take the action once the solution is confirmed.

ziyeqf avatar May 15 '24 01:05 ziyeqf

@ziyeqf

For migration to newer version, per my understanding, these resources should be swapped to go-azure-sdk first, then it will be able to be upgraded to newer API version

Yes, that is what I am now doing with Logic Apps. But that is required for the whole logic service, so that is a big work.

dkuzmenok avatar May 15 '24 05:05 dkuzmenok

Just got update this will be fixed in days on the service side, thanks for your patience.

ziyeqf avatar May 15 '24 08:05 ziyeqf

@ziyeqf Is there any decision about logic future, keeping in mind that change would be reverted? Would it be fine if we would try to migrate part to go-azure-sdk?

dkuzmenok avatar May 15 '24 11:05 dkuzmenok

Hey folks,

Our team is working on fixing this. If you need an immediate fix in the meantime, you're welcome to deploy with AzAPI instead; I've attached some code here for your convenience.

resource "azapi_resource" "resourceGroup" {
  type                      = "Microsoft.Resources/resourceGroups@2020-06-01"
  name                      = var.resource_name
  location                  = var.location
}

resource "azapi_resource" "serverfarm" {
  type      = "Microsoft.Web/serverfarms@2022-09-01"
  parent_id = azapi_resource.resourceGroup.id
  name      = var.resource_name
  location  = var.location
  body = {
    properties = {
      hyperV         = false
      perSiteScaling = false
      reserved       = false
      zoneRedundant  = false
    }
    sku = {
      name = "S1"
    }
  }
}

resource "azapi_resource" "site" {
  type      = "Microsoft.Web/sites@2022-09-01"
  parent_id = azapi_resource.resourceGroup.id
  name      = var.resource_name
  location  = var.location
  body = {
    properties = {
      clientAffinityEnabled = false
      clientCertEnabled     = false
      clientCertMode        = "Required"
      enabled               = true
      httpsOnly             = false
      publicNetworkAccess   = "Enabled"
      serverFarmId          = azapi_resource.serverfarm.id
      siteConfig = {
        acrUseManagedIdentityCreds       = false
        alwaysOn                         = true
        autoHealEnabled                  = false
        ftpsState                        = "Disabled"
        http20Enabled                    = false
        loadBalancing                    = "LeastRequests"
        localMySqlEnabled                = false
        managedPipelineMode              = "Integrated"
        minTlsVersion                    = "1.2"
        publicNetworkAccess              = "Enabled"
        remoteDebuggingEnabled           = false
        scmIpSecurityRestrictionsUseMain = false
        scmMinTlsVersion                 = "1.2"
        use32BitWorkerProcess            = true
        vnetRouteAllEnabled              = false
        webSocketsEnabled                = false
        windowsFxVersion                 = ""
      }
      vnetRouteAllEnabled = false
    }
  }
}

stemaMSFT avatar May 15 '24 22:05 stemaMSFT

@ziyeqf Is there any decision about logic future, keeping in mind that change would be reverted? Would it be fine if we would try to migrate part to go-azure-sdk?

yes, waiting for the change to be reverted is the current solution. and azapi provider could provide an immediate fix. migrating should be great, it's just, will be a large change, which cost much more time. We are also investigating about the migrating.

ziyeqf avatar May 16 '24 02:05 ziyeqf

Hey folks,

Our team is working on fixing this. If you need an immediate fix in the meantime, you're welcome to deploy with AzAPI instead; I've attached some code here for your convenience.

...

For anyone giving this workaround (which is much appreciated!) a try - thought I'd share that you will also want to add the kind property with a value of functionapp,workflowapp to the site resource's body, or the deployed Logic Apps will not display correctly in the Azure Portal.

resource "azapi_resource" "site" {
  type      = "Microsoft.Web/sites@2022-09-01"
  parent_id = azapi_resource.resourceGroup.id
  name      = var.resource_name
  location  = var.location
  body = {
    kind = "functionapp,workflowapp"
    properties = {
    ...

Looking forward to moving back to azurerm_logic_app_standard once API changes are reverted!

sneakyflint avatar May 19 '24 00:05 sneakyflint

Hi all, per our message and our testing the fix has been deployed. Could you please give it another try?

ziyeqf avatar May 22 '24 02:05 ziyeqf

@ziyeqf In our tenant after rolling back changes - everything works fine (as it was).

dkuzmenok avatar May 22 '24 07:05 dkuzmenok

I tried few minutes ago, and the issue is still persists.

gayamm avatar May 23 '24 13:05 gayamm

Also running into this issue still - US West 2 Standard Logic App. In particular, setting the identity property causes the issue (which is very odd since it's unrelated to site_config entirely):


resource "azurerm_logic_app_standard" "primary" {
  name                       = "logicapp-demo"
  version                    = "~4"
  location                   = data.azurerm_resource_group.primary.location
  resource_group_name        = data.azurerm_resource_group.primary.name
  app_service_plan_id        = data.azurerm_service_plan.primary.id
  storage_account_name       = var.storage_account.name
  storage_account_access_key = var.storage_account.access_key
  https_only                 = true

  identity {
    type = "SystemAssigned"
  }
}

Initial deploy works without identity attribute. Once we add it, it throws the error. It does work with https_only on first deploy.

cnnranderson avatar May 29 '24 18:05 cnnranderson

Hi all, per our message and our testing the fix has been deployed. Could you please give it another try?

Hi, I tried to create a standard logic app today using TF (azurerm provider version 3.105.0), I am still seeing the same error "There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property"

snehacloudops avatar May 30 '24 18:05 snehacloudops

Also running into this issue still - US West 2 Standard Logic App. In particular, setting the identity property causes the issue (which is very odd since it's unrelated to site_config entirely):


resource "azurerm_logic_app_standard" "primary" {
  name                       = "logicapp-demo"
  version                    = "~4"
  location                   = data.azurerm_resource_group.primary.location
  resource_group_name        = data.azurerm_resource_group.primary.name
  app_service_plan_id        = data.azurerm_service_plan.primary.id
  storage_account_name       = var.storage_account.name
  storage_account_access_key = var.storage_account.access_key
  https_only                 = true

  identity {
    type = "SystemAssigned"
  }
}

Initial deploy works without identity attribute. Once we add it, it throws the error. It does work with https_only on first deploy.

Hi @cnnranderson, just checked the code, identity should not affect this.

And per the message the backend team has rolled back the change, our testing were made on westeurope, francecentral and eastus2, they all succeeded for now. Since there are many regions on Azure, there might be difference and delay among them. Please give it some time and try. Thanks

ziyeqf avatar Jun 03 '24 02:06 ziyeqf

Thanks for taking the time to open this issue. Since the backend team with Microsoft rolled back the change some time ago I am going to mark this issue as closed. If this issue is still persisting, please reach out and I can reopen this issue.

rcskosir avatar Aug 27 '24 15:08 rcskosir

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[bot] avatar Sep 27 '24 02:09 github-actions[bot]