feat(vpc): OpenIaaS VM inline os_network_adapter — VPC static-IP at create (API gap: VM-create networkAdapters[] lacks ipAddress)

[pbesret]

Refs #238. Related to #A / #B. Completeness facet: place an OpenIaaS VM on a VPC private network with a chosen static IP at VM-create time, via the inline os_network_adapter block of cloudtemple_compute_iaas_opensource_virtual_machine.

Finding: this is (mostly) an API gap, not provider work

The VM-create endpoint's networkAdapters[] accepts only { networkId, mac } — there is no ipAddress field (verified in the Compute broker xoa/.../createVirtualMachineSchema.ts), unlike the standalone adapter endpoints that gained ipAddress in feat(#1854) (see #A). So a VM cannot be placed on a VPC network with a controlled static IP at create time through the inline block today.

Options

1. Platform/API request (preferred for parity): ask the Compute API team to add ipAddress to networkAdapters[].* on the OpenIaaS (and vCenter) VM-create endpoints, mirroring feat(#1854) on the standalone adapter endpoints. Track here; this is the only way to do controlled VPC addressing inline at VM creation.
2. Provider doctrine (works today, no API change): for VPC addressing, do not rely on the inline os_network_adapter; instead manage the NIC with the standalone cloudtemple_compute_iaas_opensource_network_adapter resource (#A) and set ip_address there — or update the adapter post-create. Document this clearly so users do not expect inline VPC IPs.

Scope

• Decide between (1) and (2) — recommend doing both: file the API request (1) AND ship the documented doctrine (2) in v1.9.0.
• If/when the API adds inline ipAddress: add ip_address to the provider's os_network_adapter block and to the OSNetworkAdapter client struct (CreateOpenIaasVirtualMachineRequest.NetworkAdapters).
• Documentation: make the supported path for VPC addressing explicit across the VM and adapter resources.

Note

This facet is partly blocked on an API addition (option 1), unlike #A (live-proven) and #B (API-ready, needs live VMware validation). Re-scope or down-prioritize within v1.9.0 if the inline path is not required for the first release — the standalone adapter path (#A) already delivers controlled VPC addressing.

[pbesret]

Update (product owner): attaching a network adapter to a VPC network at VM-create time is not possible yet — the Compute VM-create endpoint's networkAdapters[] does not accept ipAddress (only networkId + mac). The API addition is planned but not available, like the internet gateway (#371).

Deferring this issue accordingly:

• Blocked on the API addition (ipAddress on VM-create networkAdapters[]).
• Out of v1.9.0 scope (removed from the v1.9.0 milestone). To be picked up when the API exposes it.

The VPC-addressing capability shipped in v1.9.0 is delivered by the standalone adapter resources — #374 (OpenIaaS) and #375 (VMware) — with ip_address, plus the documented doctrine (use the standalone adapter resource for VPC addressing; the inline os_network_adapter cannot set a VPC IP at create time today).