Skip to content

infoblox_ip_fixed_address: ipv4addr field should be marked as Computed for dynamic allocation #496

@krisys76

Description

@krisys76

Issue Description

The infoblox_ip_fixed_address resource has a schema design issue where the ipv4addr field is not marked as Computed: true, causing plan-time failures when using dynamic allocation.

Problem

When using the infoblox_ip_fixed_address resource for dynamic IP allocation (providing network instead of ipv4addr), the output cannot be used as input to other resources during the Terraform plan phase because Terraform doesn't know that ipv4addr will be computed after apply.

Schema Comparison

Working Example: infoblox_ip_allocation

"allocated_ipv4_addr": {
    Type:        schema.TypeString,
    Optional:    true,
    Computed:    true,  // ← This allows plan-time dependencies
    Description: "Value which comes from 'ipv4_addr' (if specified) or from auto-allocation function",
},

Problematic: infoblox_ip_fixed_address

"ipv4addr": {
    Type:        schema.TypeString,
    Optional:    true,  // ← Missing Computed: true\!
    Description: "The IPv4 Address of the fixed address.",
},

Reproduction

resource "infoblox_ip_fixed_address" "test" {
  network_view = "default"
  network      = "10.0.1.0/24"  # Dynamic allocation
  name         = "test-host"
  match_client = "RESERVED"
}

# This fails at plan time with "Must set a configuration value for the name attribute"
resource "some_other_resource" "test" {
  name = infoblox_ip_fixed_address.test.ipv4addr
}

Expected Behavior

The ipv4addr field should be usable as input to other resources during plan time, similar to how allocated_ipv4_addr works in the infoblox_ip_allocation resource.

Suggested Solutions

Option 1: Add Computed flag to existing field (Simple)

In resource_infoblox_fixed_address.go, change:

"ipv4addr": {
    Type:        schema.TypeString,
    Optional:    true,
    Computed:    true,  // ← Add this line
    Description: "The IPv4 Address of the fixed address.",
},

Pros: Simple change, maintains single field
Cons: Potentially breaking change to existing field behavior

Option 2: Add separate allocated_ipv4_addr field (Recommended)

Add a new computed field following the infoblox_ip_allocation pattern:

// Keep existing field as-is (input)
"ipv4addr": {
    Type:        schema.TypeString,
    Optional:    true,
    Description: "The IPv4 Address of the fixed address.",
},

// Add new field (output)
"allocated_ipv4_addr": {
    Type:        schema.TypeString,
    Computed:    true,
    Description: "The allocated IPv4 address (from ipv4addr if specified, or dynamically allocated from network).",
},

Then in the resource functions, populate allocated_ipv4_addr with the final IP address:

if err = d.Set("allocated_ipv4_addr", fixedAddress.IPv4Address); err \!= nil {
    return err
}

Pros:

  • Maintains backward compatibility
  • Consistent with infoblox_ip_allocation resource
  • Clear separation between input and output
  • Follows established provider patterns

Cons: Adds another field to the schema

Recommendation

Option 2 is recommended as it:

  1. Maintains consistency across the provider
  2. Is completely backward compatible
  3. Follows the established pattern users already understand from infoblox_ip_allocation
  4. Clearly separates input from output semantics

Environment

  • Terraform Provider Version: [latest]
  • Terraform Version: [any]
  • Use Case: Using fixed address resource output as input to other resources (e.g., Ansible AWX host creation)

This issue is related to #471 but focuses specifically on the ipv4addr field computation rather than the ref field.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions