[wesleip]

Summary

Add an optional spec.tags ([]string) to the Instance, VPC, Network and SecurityGroup specs.

The control plane (virtfoundry/core) persists user-defined resource tags directly on the CR and reads them back through the REST API and UI. The field was missing from the schemas, so on a cluster with these CRDs installed, strict field validation rejects the write:

Instance in version "v1alpha1" cannot be handled as a Instance:
strict decoding error: unknown field "spec.tags"

This blocks core#256 (VM tags, already open) and the upcoming network/VPC tagging work.

• Generated with make manifests generate (config/crd/bases/*, zz_generated.deepcopy.go).
• No controller logic or RBAC changes; only the API surface gains an optional field.

Cross-repo follow-up

CRDs are shipped through the virtfoundry-crds chart in virtfoundry/helm-charts. After this merges and a version is cut, sync the regenerated CRDs there. Note that the installed CRD carries helm.sh/resource-policy: keep, so an existing cluster needs an explicit kubectl apply to pick up the new field.

Test plan

• make test
• make lint and make lint-config
• make verify-chart-rbac
• Homelab validation (create/list/edit/clear tags on a tagged resource)

[Matheus-Thurler]

Thanks, the change is small and correct. One request before merge:

• Bound the field. spec.tags has no limits, so any client can write an unbounded list to etcd. Please add markers, for example +kubebuilder:validation:MaxItems=50 and +kubebuilder:validation:items:MaxLength=63, on all four specs and regenerate.

Follow-ups after merge (not blocking this PR):

• Sync the regenerated CRDs in helm-charts (make sync-crds-chart).
• The installed CRDs carry helm.sh/resource-policy: keep, so existing clusters need an explicit kubectl apply.
• This must land and be applied before core#256 is deployed.

[wesleip]

Summary

Implemented the owner's review request from PR #74 to bound the spec.tags field.

Changes Made

Type definitions (4 files):

• api/v1alpha1/instance_types.go - Added Tags []string field with +kubebuilder:validation:MaxItems=50 and +kubebuilder:validation:items:MaxLength=63 markers to InstanceSpec
• api/v1alpha1/vpc_types.go - Added same field to VPCSpec
• api/v1alpha1/network_types.go - Added same field to NetworkSpec
• api/v1alpha1/securitygroup_types.go - Added same field to SecurityGroupSpec

Deepcopy (1 file):

• api/v1alpha1/zz_generated.deepcopy.go - Regenerated deepcopy functions for Tags []string on all 4 resource types. Added nil-check and slice copy logic.

CRDs (4 files):

• config/crd/bases/virtfoundry.io_instances.yaml - Added tags array schema with maxItems: 50, maxLength: 63
• config/crd/bases/virtfoundry.io_networks.yaml - Same
• config/crd/bases/virtfoundry.io_securitygroups.yaml - Same
• config/crd/bases/virtfoundry.io_vpcs.yaml - Same

Verification

• make build - succeeds
• make lint-config - passes

The kubebuilder markers and CRD schema now enforce maximum 50 tags per resource and maximum 63 characters per tag string, preventing unbounded writes to etcd.

---

Changes generated with make generate and make manifests