Skip to content

VMInstance: model the new disks[].hotpluggable field (upstream cozystack#3978) #35

Description

Upstream cozystack/cozystack#3978 adds an optional hotpluggable flag to each entry of the vm-instance disks list. When set, the chart marks the generated volume hotpluggable: true, which is what KubeVirt requires to attach or detach a volume while the VM is running; without it the volume only reaches the guest after a restart.

The provider models disks[] by hand as {name, bus}internal/provider/vminstance_schema.go, in the resource schema and again in the data source schema — plus the matching model and its expand/flatten pair. So the new field is not settable, and not readable either.

Shape: optional bool, no default. Two constraints worth carrying into the description rather than the validators, since both are enforced elsewhere and would drift:

  • it needs the DeclarativeHotplugVolumes feature gate on the cluster, which the provider cannot see;
  • the chart refuses hotpluggable unless bus is scsi or virtio, because KubeVirt's own admitter does (ValidateHotplugDiskConfiguration). A provider-side stringvalidator on bus would be wrong: any bus stays valid for a disk that is not hotpluggable.

Omitting the field keeps today's behaviour, so this is backward compatible.

Filed rather than sent as a PR because the api/apps/v1alpha1 pin has to move past the upstream merge first — shipping the attribute before that would give users a Terraform field that silently does nothing, which is exactly the failure mode the upstream change is meant to remove.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions