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

Cannot deploy Logic App when site_config is present in resource configuration #25891

Closed
1 task done
ghost opened this issue May 7, 2024 · 19 comments
Closed
1 task done
Labels
bug service/logic upstream/microsoft/waiting-on-service-team This label is applicable when waiting on the Microsoft Service Team v/3.x

Comments

@ghost
Copy link

ghost commented May 7, 2024

Is there an existing issue for this?

  • I have searched the existing issues

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 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

@ziyeqf
Copy link
Contributor

ziyeqf commented May 9, 2024

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.

@dkuzmenok
Copy link
Contributor

@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.

@pritiyadav537
Copy link

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?

@jobinsj27
Copy link

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.

@ziyeqf
Copy link
Contributor

ziyeqf commented May 15, 2024

@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.

@dkuzmenok
Copy link
Contributor

@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.

@ziyeqf
Copy link
Contributor

ziyeqf commented May 15, 2024

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

@dkuzmenok
Copy link
Contributor

@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?

@stemaMSFT
Copy link
Collaborator

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
    }
  }
}

@ziyeqf
Copy link
Contributor

ziyeqf commented May 16, 2024

@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.

@sneakyflint
Copy link

sneakyflint commented May 19, 2024

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!

@rcskosir rcskosir added bug upstream/microsoft/waiting-on-service-team This label is applicable when waiting on the Microsoft Service Team labels May 20, 2024
@ziyeqf
Copy link
Contributor

ziyeqf commented May 22, 2024

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

@dkuzmenok
Copy link
Contributor

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

@gayamm
Copy link

gayamm commented May 23, 2024

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

@cnnranderson
Copy link

cnnranderson commented May 29, 2024

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.

@snehacloudops
Copy link

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"

@ziyeqf
Copy link
Contributor

ziyeqf commented Jun 3, 2024

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

@rcskosir
Copy link
Contributor

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.

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 Sep 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug service/logic upstream/microsoft/waiting-on-service-team This label is applicable when waiting on the Microsoft Service Team v/3.x
Projects
None yet
Development

No branches or pull requests

10 participants