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:
- Maintains consistency across the provider
- Is completely backward compatible
- Follows the established pattern users already understand from
infoblox_ip_allocation
- 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.
Issue Description
The
infoblox_ip_fixed_addressresource has a schema design issue where theipv4addrfield is not marked asComputed: true, causing plan-time failures when using dynamic allocation.Problem
When using the
infoblox_ip_fixed_addressresource for dynamic IP allocation (providingnetworkinstead ofipv4addr), the output cannot be used as input to other resources during the Terraform plan phase because Terraform doesn't know thatipv4addrwill be computed after apply.Schema Comparison
Working Example:
infoblox_ip_allocationProblematic:
infoblox_ip_fixed_addressReproduction
Expected Behavior
The
ipv4addrfield should be usable as input to other resources during plan time, similar to howallocated_ipv4_addrworks in theinfoblox_ip_allocationresource.Suggested Solutions
Option 1: Add Computed flag to existing field (Simple)
In
resource_infoblox_fixed_address.go, change: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_allocationpattern:Then in the resource functions, populate
allocated_ipv4_addrwith the final IP address:Pros:
infoblox_ip_allocationresourceCons: Adds another field to the schema
Recommendation
Option 2 is recommended as it:
infoblox_ip_allocationEnvironment
This issue is related to #471 but focuses specifically on the
ipv4addrfield computation rather than thereffield.