oci network vnic assign-ipv6 crashes with TypeError: ... 'hostname' (regression in 3.86.0)

[atiqrahmanx]

Summary

oci network vnic assign-ipv6 raises a Python TypeError at function-call time and never reaches the API. It is reproducible with any arguments and affects 3.86.0 through the current 3.89.0. It worked through 3.85.0.

Reproduce

pip install oci-cli==3.86.0
oci network vnic assign-ipv6 --vnic-id ocid1.vnic.oc1..anything

Result:

TypeError: assign_ipv6() got an unexpected keyword argument 'hostname'

The error is raised before any network/API call, so it fires regardless of the vnic-id value.

Regression boundary

oci-cli	bundled oci (SDK)	assign-ipv6 --help shows --hostname?	result
3.85.0	2.177.0	no	reaches API (no TypeError)
3.86.0	2.178.0	yes	TypeError (broken)
3.88.0	2.180.0	yes	broken
3.89.0 (latest)	2.181.0	yes	broken

Root cause

assign-ipv6 is hand-written in services/core/src/oci_cli_virtual_network/virtualnetwork_cli_extended.py and its click options are copied from the auto-generated create_ipv6 command via:

@cli_util.copy_params_from_generated_command(virtualnetwork_cli.create_ipv6, ...)

The hand-written signature is static and does not declare hostname:

def assign_ipv6(ctx, from_json, vnic_id, defined_tags, display_name, freeform_tags,
                ip_address, unassign_if_already_assigned, ipv6_subnet_cidr,
                route_table_id, lifetime, cidr_prefix_length):

In SDK 2.178.0 (commit 40a0ec43cc, "Releasing version 2.178.0", 2026-06-09) a hostname field was added to CreateIpv6Details (src/oci/core/models/create_ipv6_details.py). That caused the generated create_ipv6 command to gain a --hostname option, which copy_params_from_generated_command then attached to assign-ipv6. Click passes hostname= into assign_ipv6(), which does not accept it -> TypeError.

I verified the bisect by checking create_ipv6_details.py at each release tag: the hostname property is absent at 2.168.2 and earlier, present at 2.178.0; oci-cli pins the SDK exactly (oci==2.178.0 in 3.86.0's setup.py).

Suggested fix

Add hostname to the assign_ipv6 signature (and forward it into assign_ip_request_body), mirroring how display_name is handled. The adjacent unassign_ipv6 likely has the same latent issue if delete_ipv6/update_ipv6 ever gains the field. Alternatively, decouple assign-ipv6 from copy_params_from_generated_command so generated-command option drift cannot silently break the hand-written signature.

Workaround

Pin to oci-cli<=3.85.0 (e.g. 3.85.0, which bundles oci==2.177.0). All other commands work on the latest release; only assign-ipv6 is affected.

Environment

• Reproduced on Python 3.12 and 3.14, macOS aarch64
• oci-cli 3.86.0 / 3.88.0 / 3.89.0 (all broken); 3.85.0 and 3.71.4 (work)

[riyaKaushik576]

Hi @atiqrahmanx! Thank you for bringing this to our attention. I have created an internal ticket on this service.