sudo87 opened a new pull request, #311:
URL: https://github.com/apache/cloudstack-terraform-provider/pull/311
## Summary
`cloudstack_ipaddress` currently always lets CloudStack auto-select the next
free IP — there's no way to request a specific address. This blocks a common
pattern: an operator dedicates an intranet VLAN/IP range to an account, and
the tenant needs to acquire one *particular* address from it (e.g. because
firewall rules, DNS, or routing on the corporate side are already provisioned
for that exact IP).
The CloudStack API (`associateIpAddress`) already accepts an optional
`ipaddress` parameter; the provider never called it.
Fixes #291
## Changes
* `ip_address` changes from `Computed`-only to `Optional + Computed +
ForceNew`.
There's no CloudStack API to change an IP association in place, so a change
to `ip_address` correctly triggers destroy+recreate.
* `resourceCloudStackIPAddressCreate` passes the value through to
`AssociateIpAddressParams.SetIpaddress` when set.
* No changes to `Read`/`Delete` — the allocated address was already read back
from the API response.
* New acceptance test, `TestAccCloudStackIPAddress_specificIP`, requesting a
specific address from a dedicated `cloudstack_vlan_ip_range` so the
assertion is deterministic (the shared default pool can't guarantee a given
address is free).
* Documented the new argument in `website/docs/r/ipaddress.html.markdown`.
## Backward compatibility
Since `ip_address` was `Computed`-only before this change, no existing
configuration could have set it — Terraform rejects a config value for a
`Computed`-only attribute at validate time. The schema change is purely
additive; existing state with `ip_address` populated shows no diff.
## Testing
Verified against a simulator
* All pre-existing `cloudstack_ipaddress` acceptance tests pass unchanged
(`_basic`, `_vpc`, `_vpcid_with_network_id`).
* New `_specificIP` test passes.
* Downstream consumers unaffected: `data_source_cloudstack_ipaddress`,
`cloudstack_loadbalancer_rule` (all 5 variants), `cloudstack_static_nat`.
* Idempotent: `terraform plan`/`apply` with `ip_address` set and unchanged
produces no diff and performs no actions; same when `ip_address` is
omitted from config against existing state.
* Requesting an address already in use, or one outside any configured range,
both fail clearly with `CloudStack API error 533: Insufficient address
capacity` — no CloudStack-side ambiguity to handle.
* Changing `ip_address` correctly triggers `ForceNew`, scoped to only the
`cloudstack_ipaddress` resource (the associated network is untouched).
* Manually verified (not yet covered by the automated test):
`vpc_id` + `ip_address`, and `is_portable = true` + `ip_address` — both
work
correctly and are idempotent.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
