See https://github.com/cdktf/cdktf-provider-azurerm/actions/runs/5966228149

See https://github.com/cdktf/cdktf-provider-azurerm/actions/runs/6547319026

See https://github.com/cdktf/cdktf-provider-azurerm/actions/runs/5971716502

This might rather be a question or starting point for discussion instead of an issue, but I hope it's still the right place to address it.

Issue description

When using the prebuilt providers, such as the azurerm provider, cdktf generates the required_providers section like this:

"azurerm": {
  "version": "~> 2.0",
  "source": "azurerm"
},

This essentially causes terraform to always fetch the latest 2.0 provider, no matter what the prebuilt provider package was built against. Currently there seems to be no way to manually change that value to downgrade or pin the provider.

Background

This is especially problematic for environments where you need reproducible builds. I.e., in our application we deliberately use a yarn.lock (as probably many other teams do as well; same with package-lock.json) to pin working configurations in order for CI/CD pipelines to "replay" them consistently. Pinning there currently still does not pin the actual provider that is used.

To give a real example with impact: our pipelines started to fail last friday due to a bug in the 2.86 release, although we didn't change anything in the configuration. As a temporary workaround, we now had to revert back to the generated provider instead of the prebuilt one to pin it to version 2.85, which, unfortunately, also required quite some code changes in the import statements.

Fix / Suggestion

It would be great if either:

• One could somehow override the required_providers field to a custom version, or
• The prebuilt provider always pins to the exact terraform provider it was built against, e.g. 0.2.10 to 2.78.0. This would allow the users to control the provider version via package.json and the corresponding lock files. But one downside is that it would also tightly couple the release cycle of the prebuilt provider to the upstream terraform provider (if that's not already the case?).

Looking forward to hear feedback and opinions on that.

See https://github.com/cdktf/cdktf-provider-azurerm/actions/runs/4954968115

See https://github.com/cdktf/cdktf-provider-azurerm/actions/runs/6508956352

Looking to consume the changes here - hashicorp/terraform-cdk#1675 - but looks like the pypi train hasn't been updated since April.

https://pypi.org/project/cdktf-cdktf-provider-azurerm/#history

Trying to deploy a stack with a PrivateEndpoint that has privateServiceConnection.isManualConnection set to false, fails to deploy. The generated terraform template doesn't have the is_manual_connection field, and then terraform fails to run the deployment, saying it's mandatory.

If I flip the flag to true, only then it appears in the generated terraform template.

Example code snippet:

new PrivateEndpoint(this, "endpoint", {
  name: "endpoint",
  resourceGroupName: rg.name,
  location: rg.location,
  subnetId: subnet.id,

  privateDnsZoneGroup: {
    name: "privatednszonegroup",
    privateDnsZoneIds: [dns.id],
  },

  privateServiceConnection: {
    name: "appservice-privateconnection",
    privateConnectionResourceId: app.id,
    subresourceNames: ["sites"],
    isManualConnection: false,
  },
});

The generated terraform template, doesn't have the is_manual_connection field:

    "azurerm_private_endpoint": {
      "endpoint": {
        "location": "${azurerm_resource_group.rg.location}",
        "name": "endpoint",
        "resource_group_name": "${azurerm_resource_group.rg.name}",
        "subnet_id": "${azurerm_subnet.subnet.id}",
        "private_dns_zone_group": {
          "name": "privatednszonegroup",
          "private_dns_zone_ids": [
            "${azurerm_private_dns_zone.private-dns-zone.id}"
          ]
        },
        "private_service_connection": {
          "name": "appservice-privateconnection",
          "private_connection_resource_id": "${azurerm_app_service.app-service.id}",
          "subresource_names": [
            "sites"
          ]
        },

dependencies installed (package.json):

  "dependencies": {
    "@cdktf/provider-azurerm": "^0.3.74",
    "cdktf": "^0.8.1",
    "constructs": "^10.0.12"
  },

See https://github.com/cdktf/cdktf-provider-azurerm/actions/runs/8290942857

Prebuilt support for azurerm is great, but, given how much of Azure's identity is built on top of Azure Active Directory, it'd be great to have a prebuilt for azuread as well.

Thanks!

The provider is not in sync with latest version 2.77 release

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs#features

It's missing

The api_management block supports the following:

purge_soft_delete_on_destroy - (Optional) Should the azurerm_api_management resources be permanently deleted (e.g. purged) when destroyed? Defaults to false.

https://github.com/hashicorp/cdktf-provider-azurerm/blob/main/src/azurerm-provider.ts