[AVM Module Issue]: network variable can be simplified, and needs a fix for resource group assumption

[kewalaka]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

(Optional) Module Version

0.20

(Optional) Correlation Id

No response

Description

The name and resource_group_name inputs can be removed from this:

terraform-azurerm-avm-ptn-aks-production/variables.tf

Lines 17 to 25 in 3005b77

	variable "network" {
	type = object({
	name = string
	resource_group_name = string
	node_subnet_id = string
	pod_cidr = string
	})
	description = "Values for the networking configuration of the AKS cluster"
	}

I don't think the vnet name is being used, and the resource group name can be fetched from a subnet ID via a split, something like this:

locals { 
  vnet_resource_group_name = split("/", var.network.node_subnet_id)[4]
}

Furthermore, when setting the Network Contributor role assignment we're assuming the vnet is in the same RG as the AKS cluster, which is not a certainty.

terraform-azurerm-avm-ptn-aks-production/main.tf

Lines 45 to 49 in 3005b77

	resource "azurerm_role_assignment" "network_contributor_on_resource_group" {
	principal_id = data.azurerm_user_assigned_identity.cluster_identity.principal_id
	scope = data.azurerm_resource_group.this.id
	role_definition_name = "Network Contributor"
	}

..ln 47 should then point to local.vnet_resource_group_name

Using the above approach also means you can drop the data source for the resource group:

terraform-azurerm-avm-ptn-aks-production/main.tf

Lines 36 to 38 in 3005b77

	data "azurerm_resource_group" "this" {
	name = var.resource_group_name
	}

.... this reliance on a data source for resource group properties is an antipattern that should be avoided, as changes to RG properties can trigger "not known before apply" issues and resource re-creation.

The UAMI can just use var.resource_group_name.

[zioproto]

Thank you !

I think we broke quite a few things when based on user feedback we moved the vnet creation outside of the module in #124

@kewalaka would you like to propose a PR that addresses the above comments ?

[kewalaka]

Sure I'm currently going through a deployment where I'm switching from code for AKS Automatic to use this to deploy a standard cluster.

There some alignment I'd like to land, will be raising issues to track it first.

A gap for me is monitoring, I have mimicked the grafana and prometheus deployed by Automatic, is there interest in adding this as optional feature to this pattern?

[zioproto]

@kewalaka if I understand correctly you want to use Managed Prometheus and Managed Grafana.

For Managed Prometheus in Terraform you need a azurerm_monitor_data_collection_rule_association resource where the target_resource_id is the resource id of the AKS cluster.

Then the azurerm_dashboard_grafana resource has a block to link to prometheus like:

  azure_monitor_workspace_integrations {
    resource_id = azurerm_monitor_workspace.prometheus.id
  }

I have a full example here.

Now the design question is:

1. We could do something similar to that example I pasted above:
2. We could have first AVM resource modules for managed prometheus and managed grafana and call those modules from within this pattern module.

[kewalaka]

My code mimics the monitoring resource outputs of AKS Automatic, thus is similar but more comprehensive then the full example supplied.

Regardless of whether it is created via a resource module or directly as resources, we should look for something more aligned to the implementation created by the automatic SKU, in my opinion.

I was more looking for whether a PR along these lines would be accepted, I'll raise a separate issue in a while.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-terraform) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-terraform) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-terraform) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[nellyk]

@kewalaka hi did you get a chance to work on this?

[kewalaka]

@nellyk please see my feedback in #161 - noting this didn't have merge conflicts when I raised it, and i've already resolved merge conflicts once.

I'm happy to resolve them again but I'd like you know if the fixes are of interest, and whether you'd like monitoring split out, before I invest more time in contribution.

What I raised in that PR is what I needed with a customer to get this to the point it had the necessary features enabled for production readiness.

Please let me know how you'd like to proceed.