oci network vnic assign-ipv6 crashes with TypeError: ... 'hostname' (regression in 3.86.0)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 669
- Forks
- 236
- Avg merge
- 1m
- Merged PRs (30d)
- 4
Description
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)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in services/core/src/oci_cli_virtual_network/virtualnetwork_cli_extended.py at the hand-written assign_ipv6 entry point, then compare its copied options with create_ipv6 and the hostname field in src/oci/core/models/create_ipv6_details.py. Run the documented oci network vnic assign-ipv6 reproduction across the affected SDK versions. Done means the command no longer raises the hostname TypeError and passes hostname through to the request body.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, cloud
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100