Add Traffic Manager Endpoint module supporting all routing methods

[SazniMohamed]

Change Description

• New Features
  • Comprehensive endpoint configuration supporting Performance, Weighted, Priority, Geographic, Multivalue, and Subnet routing; custom headers, enabled/always-serve flags, weight, priority, endpoint location, geo mappings, and subnet ranges; input validations for routing method and location.

[coderabbitai]

Walkthrough

Adds public Terraform variables and a provider/version constraint, and defines six conditionally-created azurerm_traffic_manager_external_endpoint resources (Performance, Weighted, Priority, Geographic, Multivalue, Subnet) with dynamic custom_header blocks and routing-specific attributes.

Changes

Cohort / File(s)	Summary
Terraform Version Constraints modules/azurerm/Traffic-Manager-External-Endpoint/versions.tf	Adds required Terraform version >= 0.13 and azurerm provider constraint >= 3.0.0.
Input Variables modules/azurerm/Traffic-Manager-External-Endpoint/variables.tf	Adds public variables: endpoint_name (string), profile_id (string), target (string), routing_method (string, validated allowlist), custom_headers (list(object({ header_name=string, header_value=string })), default=[]), always_serve_enabled (bool, default=false), enabled (bool, default=true), weight (number, default=1), priority (number, default=1), endpoint_location (string, default="" with conditional validation for Performance), geo_mappings (list(string), default=[]), and subnets (list(object({ first=string, last=optional(string), scope=optional(string) })), default=[]).
Endpoint Resources modules/azurerm/Traffic-Manager-External-Endpoint/traffic_manager_external_endpoint.tf	Adds six azurerm_traffic_manager_external_endpoint resources selected via count on routing_method: performance_based_external_endpoint, weighted_based_external_endpoint, priority_based_external_endpoint, geographic_based_external_endpoint, multivalue_based_external_endpoint, and subnet_based_external_endpoint. Each sets common fields (name, profile_id, target, always_serve_enabled, enabled) and dynamic custom_header blocks; routing-specific attributes include endpoint_location, weight, priority, geo_mappings, and dynamic subnet blocks.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Verify variable validation logic (routing_method allowlist and conditional requirement for endpoint_location).
• Check object schemas for custom_headers and subnets and their iteration/mapping in dynamic blocks.
• Confirm count conditions correctly enforce exclusive resource creation for each routing method.
• Inspect routing-specific attributes (weight, priority, geo_mappings) for provider compatibility and expected types.

Poem

🐇 I nibbled through vars by lantern light,
Six endpoints blooming in the night,
Headers flit and subnets hop in tune,
Performance, weight, and geo under the moon,
A rabbit's cheer — the module's right! 🥕✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The pull request description significantly deviates from the required template structure and lacks most essential sections.	Complete the PR description following the template: add Purpose with issue links, Goals, Approach, User stories, Release notes, Documentation, and other required sections. Replace placeholder text with actual implementation details.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main objective: adding a Traffic Manager Endpoint module that supports all routing methods. It aligns well with the substantial changes to variables, resources, and configuration files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4c6f76a and 77d79d8.

📒 Files selected for processing (3)

• modules/azurerm/Traffic-Manager-External-Endpoint/traffic_manager_priority_external_endpoint.tf (1 hunks)
• modules/azurerm/Traffic-Manager-External-Endpoint/variables.tf (1 hunks)
• modules/azurerm/Traffic-Manager-External-Endpoint/versions.tf (1 hunks)

🔇 Additional comments (3)

modules/azurerm/Traffic-Manager-External-Endpoint/versions.tf (1)

21-29: Terraform and provider version constraints look good.

The constraints are well-configured and reasonable for this module.

modules/azurerm/Traffic-Manager-External-Endpoint/traffic_manager_priority_external_endpoint.tf (2)

1-35: Scope mismatch: filename and resource naming vs. implementation.

The filename traffic_manager_priority_external_endpoint.tf and resource name performace_based_external_endpoint suggest this handles Priority routing, but the implementation only creates resources when var.routing_method == "Performance" (line 22). Verify whether:

• This module is intended to support all routing methods (Priority, Performance, Weighted, Geographic, Multivalue, Subnet)
• Other routing methods are handled in separate files within this module
• The filename and PR description accurately reflect the current scope

If all routing methods are intended, expand the implementation to include them. If only Performance routing is supported, rename the file to clarify scope.

---

27-33: The custom_header field mapping is correct.

The dynamic block properly maps custom_header.value.header_name and custom_header.value.header_value to the name and value fields, which are the exact field names expected by the azurerm_traffic_manager_external_endpoint provider's custom_header block. No changes needed.

[coderabbitai]

Actionable comments posted: 2

♻️ Duplicate comments (2)

modules/azurerm/Traffic-Manager-External-Endpoint/variables.tf (2)

36-39: Routing_method variable still lacks validation (unresolved from past review).

The variable accepts any string value despite the description listing valid values (Performance, Priority, Weighted, Geographic, Multivalue, Subnet). Without validation, invalid values bypass the conditional count logic in the endpoint resources, causing unexpected behavior. Add a validation block to enforce allowed values.

 variable "routing_method" {
   description = "Routing method for the Traffic Manager Profile. Valid values are 'Performance', 'Priority', 'Weighted', 'Geographic', 'Multivalue', 'Subnet'"
   type        = string
+
+  validation {
+    condition     = contains(["Performance", "Priority", "Weighted", "Geographic", "Multivalue", "Subnet"], var.routing_method)
+    error_message = "Routing method must be one of: Performance, Priority, Weighted, Geographic, Multivalue, or Subnet."
+  }
 }

---

74-78: Remove empty string default for endpoint_location (unresolved from past review).

The description states this is "Required for Performance routing method," but the empty string default masks this requirement. When Performance routing is selected without an explicit location, Azure deployment will fail. Remove the default to make it required, or add conditional validation that enforces presence when routing_method is "Performance".

 variable "endpoint_location" {
   description = "Location of the endpoint. Required for Performance routing method. The location must be specified for endpoints of types: 'Performance'"
   type        = string
-  default     = ""
 }

Alternatively, add conditional validation:

 variable "endpoint_location" {
   description = "Location of the endpoint. Required for Performance routing method. The location must be specified for endpoints of types: 'Performance'"
   type        = string
   default     = ""
+
+  validation {
+    condition     = var.routing_method != "Performance" || var.endpoint_location != ""
+    error_message = "endpoint_location is required when routing_method is Performance."
+  }
 }

🧹 Nitpick comments (1)

modules/azurerm/Traffic-Manager-External-Endpoint/variables.tf (1)

62-72: Add validation for weight and priority ranges.

The descriptions state valid ranges (1-1000) but no validation blocks enforce these constraints. This could allow users to pass invalid values that fail during deployment. Add validation blocks to match the stated constraints.

 variable "weight" {
   description = "Weight of the endpoint. Required for Weighted routing method. Valid values are between 1 and 1000"
   type        = number
   default     = 1
+
+  validation {
+    condition     = var.weight >= 1 && var.weight <= 1000
+    error_message = "Weight must be between 1 and 1000."
+  }
 }

 variable "priority" {
   description = "Priority of the endpoint. Required for Priority routing method. Valid values are between 1 and 1000"
   type        = number
   default     = 1
+
+  validation {
+    condition     = var.priority >= 1 && var.priority <= 1000
+    error_message = "Priority must be between 1 and 1000."
+  }
 }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f0054ae and 8efaa1c.

📒 Files selected for processing (2)

• modules/azurerm/Traffic-Manager-External-Endpoint/traffic_manager_external_endpoint.tf (1 hunks)
• modules/azurerm/Traffic-Manager-External-Endpoint/variables.tf (1 hunks)

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

modules/azurerm/Traffic-Manager-External-Endpoint/traffic_manager_external_endpoint.tf (1)

21-127: Consider refactoring to reduce code duplication.

The six resources follow an identical pattern with only routing-method-specific attributes varying. You could improve maintainability by using a single resource with a for_each loop over a map of routing method configurations, or by extracting common attributes into a local variable. This would eliminate repetitive code while maintaining clarity.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 80d0428 and ea2cb70.

📒 Files selected for processing (2)

• modules/azurerm/Traffic-Manager-External-Endpoint/traffic_manager_external_endpoint.tf (1 hunks)
• modules/azurerm/Traffic-Manager-External-Endpoint/variables.tf (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• modules/azurerm/Traffic-Manager-External-Endpoint/variables.tf

🔇 Additional comments (2)

modules/azurerm/Traffic-Manager-External-Endpoint/traffic_manager_external_endpoint.tf (2)

21-21: Good—typos have been fixed.

The resource names are now correctly spelled as performance_based_external_endpoint (line 21) and multivalue_based_external_endpoint (line 89), addressing the prior review comments.

Also applies to: 89-89

---

21-127: Verify variable structure matches dynamic block expectations.

The dynamic blocks assume specific variable structures (e.g., custom_header.value.header_name and subnet.value.first) that must be validated in variables.tf. Additionally, verify that all six routing methods legitimately support the custom_header block—particularly the Subnet method, which appears as the only outlier in typical Azure Traffic Manager patterns.

Please confirm:

1. var.custom_headers is defined as a list of objects with header_name and header_value fields
2. var.subnets is defined as a list of objects with first, last, and scope fields
3. All routing methods (including Subnet) support the custom_header block in your provider version

You can verify this by examining variables.tf and consulting the Azure provider documentation for the endpoint resource.