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_api_management_api_schema doesn't work with JSON schemas #10066

Open
ivarec opened this issue Jan 6, 2021 · 7 comments
Open

azurerm_api_management_api_schema doesn't work with JSON schemas #10066

ivarec opened this issue Jan 6, 2021 · 7 comments

Comments

@ivarec
Copy link

ivarec commented Jan 6, 2021

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 0.14.3
terraform-provider-azurerm 2.41.0

Affected Resource(s)

  • azurerm_api_management_api_schema

Terraform Configuration Files

resource "azurerm_api_management_api_schema" "example" {
  api_name            = data.azurerm_api_management_api.example.name
  api_management_name = data.azurerm_api_management_api.example.api_management_name
  resource_group_name = data.azurerm_api_management_api.example.resource_group_name
  schema_id           = "example-schema"
  content_type        = "application/vnd.oai.openapi.components+json"
  value               = <<-JSON
  {
      "MyDefinition": {
          "type": "string"
      }
  }
  JSON
}

Expected Behaviour

MyDefinition should appear in Azure's APIM definitions for my API.

Actual Behaviour

The definition doesn't get created. The schema resource was created in a broken state.

Steps to Reproduce

  1. terraform apply
    (given that you have created some stub dependencies)

Important Factoids

I've noticed that the ARM template that gets created by Terraform is wrong for JSON schemas. According to the documentation, the document field can be one of these two elements:

  • object with a "root" key named value that is of type string (meant for anything other than JSON)
  • object with a "root" key named definitions that is of type object (meant for JSON schemas). This is the broken (unsupported) scenario

I can see two obvious solutions to this problem:

  1. check the content of content_type and then decide if Terraform is going to create a template with value as a string or definitions as an object
  2. add a new field called definitions that will serialize to the definitions object and have Terraform forbid that both value and definitions is set

References

https://docs.microsoft.com/en-us/azure/templates/microsoft.apimanagement/service/apis/schemas#SchemaContractProperties

@jz-wilson
Copy link

Do you have a workaround for this? I'm trying to either make my own ARM template to create this or do some az cli commands to get this automated.

@jz-wilson
Copy link

The version_set_id from the resource azurerm_api_management_api generates the schema_id.

So I actually figured out a way to do this using ARM templates:

locals {
  api_version_set_id_split = split("/", azurerm_api_management_api.api.version_set_id)
  api_schema_id            = element(local.api_version_set_id_split, length(local.api_version_set_id_split) - 1)
}
resource "azurerm_resource_group_template_deployment" "api_management_schema" {
  deployment_mode     = "Incremental"
  name                = "api_management_schema"
  resource_group_name = var.resource_group
  parameters_content = jsonencode({
    apim_name = {
      value = data.azurerm_api_management.apim.name
    }
    apim_api_name = {
      value = "apim-name"
    }
    api_schema_id = {
      value = local.api_schema_id
    }
  })
  template_content = file("./api_management_schema.json")
  tags             = local.common_tags
}

api_management_schema.json

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "apim_name": {
      "type": "string"
    },
    "apim_api_name": {
      "type": "string"
    },
    "api_schema_id": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.ApiManagement/service/apis/schemas",
      "apiVersion": "2021-08-01",
      "name": "[concat(parameters('apim_name'), '/', parameters('apim_api_name'), '/', parameters('api_schema_id'))]",
      "properties": {
        "contentType": "application/vnd.oai.openapi.components+json",
        "document": {
          "components": {
            "schemas": { ... }
          }
        }
      }
    }
  ]
}

@LoW0lf
Copy link

LoW0lf commented Feb 17, 2022

Is is also to consider that while the schema is deployed in this "broken" state (as mentioned in original post), the "schema definitions" part of API Management seems to get broken as well. I did not manage to create additional schema definitions anymore via portal (endless loop). Removing the broken schema resources in terraform code was the only way to get it back to a working state. Would be really nice to see a fix here.

@jz-wilson Thank you very much for sharing the work-around, it fits for me as well.

@wolfm89
Copy link

wolfm89 commented Jun 28, 2022

This issue is still blocking the creation and usage of new API schemas. Any updates about fixing this?

@imduchy
Copy link
Contributor

imduchy commented Aug 24, 2022

Experiencing the same issue with Terraform v1.2.3 and azurerm 3.14.0

@arkiaconsulting
Copy link

It looks like #18394 may help

@zXynKs
Copy link

zXynKs commented Mar 16, 2023

I believe I'm having the same problem. Question has been asked on Stack Overflow along with steps to recreate:
https://stackoverflow.com/questions/75746448/azure-apim-deploying-a-schema-via-terraform/75756445

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants