instance-configuration create silently drops bootVolumeSizeInGBs/bootVolumeVpusPerGB when passed kebab-case (get output not round-trippable)

Summary

oci compute-management instance-configuration create silently drops the boot-volume sizing fields (bootVolumeSizeInGBs, bootVolumeVpusPerGB) when they are supplied using the kebab-case names that instance-configuration get emits (boot-volume-size-in-gbs, boot-volume-vpus-per-gb).

The created instance configuration ends up with boot-volume-size-in-gbs: null, so any instance / instance-pool / cluster-network launched from it gets the image's default boot-volume size instead of the intended size. No error or warning is printed.

This breaks the natural get → modify → create round trip: you cannot take instance-configuration get output, change one field, and feed it back to create, because the boot-volume fields are lost in the process.

Root cause (apparent)

The CLI's kebab→camelCase normalization mishandles the GB(s) acronym:

Input (kebab, as get emits)	CLI normalizes to	SDK model field (expected)
boot-volume-size-in-gbs	bootVolumeSizeInGbs (lowercase b)	bootVolumeSizeInGBs (capital GB)
boot-volume-vpus-per-gb	bootVolumeVpusPerGb (lowercase b)	bootVolumeVpusPerGB (capital GB)

Because the normalized key doesn't match the model attribute, the value is silently discarded. Other kebab-case fields in the same payload (e.g. instance-options.are-legacy-imds-endpoints-disabled, metadata, create-vnic-details.nsg-ids) round-trip fine — only the GB/GBs acronym fields are affected.

Environment

• oci-cli version: 3.54.0
• OS: macOS (darwin)
• Auth: security token

Affected commands

• oci compute-management instance-configuration create --instance-details file://...
• oci compute-management instance-configuration create --from-json file://... (same result — both paths drop it)
• Field location: instanceDetails.launchDetails.sourceDetails (InstanceConfigurationInstanceSourceViaImageDetails)

Reproduction

1. Build an instance-details file using the kebab-case names exactly as instance-configuration get outputs them:

// details-kebab.json
{
  "instance-type": "compute",
  "launch-details": {
    "compartment-id": "ocid1.compartment.oc1..aaaaREDACTED",
    "shape": "VM.Standard.E4.Flex",
    "shape-config": { "ocpus": 1, "memory-in-gbs": 16 },
    "source-details": {
      "source-type": "image",
      "image-id": "ocid1.image.oc1..aaaaREDACTED",
      "boot-volume-size-in-gbs": 200,
      "boot-volume-vpus-per-gb": 10
    },
    "create-vnic-details": { "subnet-id": "ocid1.subnet.oc1..aaaaREDACTED" }
  }
}

2. Create the instance configuration:

oci compute-management instance-configuration create \
  --compartment-id ocid1.compartment.oc1..aaaaREDACTED \
  --display-name repro-kebab \
  --instance-details file://details-kebab.json

3. Inspect the created config's source-details:

oci compute-management instance-configuration get \
  --instance-configuration-id <new-ocid> \
  --query 'data."instance-details"."launch-details"."source-details"'

Expected

{
  "boot-volume-size-in-gbs": 200,
  "boot-volume-vpus-per-gb": 10,
  "image-id": "ocid1.image...",
  "source-type": "image"
}

Actual

{
  "boot-volume-size-in-gbs": null,
  "boot-volume-vpus-per-gb": null,
  "image-id": "ocid1.image...",
  "source-type": "image"
}

Workaround

Supply the two fields using the exact SDK camelCase (note the capital GB):

"source-details": {
  "sourceType": "image",
  "imageId": "ocid1.image...",
  "bootVolumeSizeInGBs": 200,
  "bootVolumeVpusPerGB": 10
}

With these names the values persist correctly (verified: created config reports boot-volume-size-in-gbs: 200).

Impact

• Silent data loss in a very common clone-and-modify workflow (get → tweak → create). The boot volume regresses to the image default with no error.
• Instances / instance pools / cluster networks launched from the resulting config come up with undersized boot volumes, leading to disk-pressure / out-of-space failures that are hard to trace back to this casing issue.

Suggested fix

• Make the kebab→camel normalization acronym-aware for these fields (*-in-gbs → InGBs, *-per-gb → PerGB), and/or
• Emit a warning (or error) when an input key in a complex parameter does not map to any known model attribute, instead of silently dropping it. The silent drop is what makes this dangerous.

Start by tracing the CLI's kebab-to-camelCase normalization for complex parameters used by instance-configuration create, focusing on instanceDetails.launchDetails.sourceDetails. Reproduce the command with details-kebab.json, then verify that boot-volume-size-in-gbs and boot-volume-vpus-per-gb persist in instance-configuration get output instead of becoming null.