Aleksei Sviridkin
4c3692b0da
KubeVirt 1.9 changes what an unlisted Beta gate means. On 1.8 isFeatureGateEnabled ended in `return false`; on 1.9 IsEnabled ends in `return fg.State == Beta`. Sixteen gates are Beta at 1.9.0 and none of them is in this chart's featureGates list, so all sixteen arrive on with the bump. The CR writes three of them back into disabledFeatureGates. Template deploys the virt-template aggregated API server: two Deployments, two APIServices, a webhook and a ValidatingAdmissionPolicy that nothing on the platform uses, and one more aggregated API to break discovery. Upstream also has spec.configuration.virtTemplateDeployment, but it reads TemplateEnabled() first, so it stops the deployment and leaves the gate and its API on; the gate stops both. ExternalNetResourceInjection makes virt-controller skip multus.NetworkToResource, so a NetworkAttachmentDefinition's k8s.v1.cni.cncf.io/resourceName no longer becomes a resource request on the launcher pod. That is right for a cluster running a network-resources-injector, which this platform does not deploy: with the gate on, a VM on an SR-IOV network schedules without its device. ImageVolume is the one that depends on the host, so it is disabled by cluster version rather than always. With it on, virt-controller drops the containerDisk sidecars and mounts the image as a VolumeSource.Image volume. Kubernetes has its own ImageVolume gate, off by default until 1.35, and an apiserver with it off strips every image volume and the mounts referencing it — dropImageVolumes in pkg/api/pod/util.go — so the launcher pod is admitted without the disk it needs and fails looking for it. KubeVirt has no capability check to notice. The management cluster is supported from 1.33, so below 1.35 the chart keeps the gate off and the sidecar path in use, and from 1.35 leaves it alone. The rest of the Beta set stays on, but a cluster may be unable to carry a given gate. A disabledFeatureGates list in the chart values appends to the static opt-outs for that case, and naming a static opt-out again renders one entry, since the operator writing down what their cluster declines has no reason to know the chart already disables it. A gate named in both lists is not a configuration KubeVirt honours, and it fails differently depending on when it lands. The update validator refuses the write and runs with failurePolicy Fail, so on a cluster that already has the CR the HelmRelease stops converging with every other field in it. The create admitter validates nothing and virt-config reads featureGates before disabledFeatureGates, so a fresh install is admitted and the gate stays on while the values file says it is off. The template stops the render and names the gate instead. The guard reads the same version-conditional list as the render, so extraFeatureGates may ask for ImageVolume exactly where the chart is not disabling it. Which list the colliding gate came from decides what the operator can do about it, so the message splits three ways: Template is pinned off and cannot be asked back, a gate the chart enables cannot be switched off from values at all, and anything else arrived through extraFeatureGates and can leave from either side. HotplugVolumes carries a note now. It is deprecated at 1.9 in favour of DeclarativeHotplugVolumes, but virt-api accepts kubevirt-csi's VMI-level removevolume on a VM-owned VMI only while the gate is on, so tenant volume detach depends on the pin, and the pin in turn keeps the newly default-on DeclarativeHotplugVolumes inert. The update target's header stops describing the two lists as curated defaults and says to check them against the pinned release's featuregate registrations at each bump, since a gate that reached GA is enabled whether the CR names it or not. make update grows a marker per line of the new block. Every insert in that target is guarded by one directive it also inserts, so a hand-merge that keeps the directive and drops a sibling line leaves the guard satisfied, the insert skipped and the render green. The three static entries are the only lines these inserts add that are CR content in their own right rather than a wrapper around a value: their absence cannot surface as a value that stopped taking effect, the CR simply goes back to deploying virt-template, to letting KubeVirt skip NAD resource injection, and to image volumes an apiserver below 1.35 discards. The target cannot rebuild a partial block, so it names the missing marker and stops. The block it does rebuild is compared against the committed one byte for byte, because the insert text and the template are two copies of the same lines and only one of them renders. The tail also greps for the guard header the block's skip reads, which no insert restores: losing it makes the template unrenderable, and that is the one hand-merge loss the tail would otherwise wave through. The suite states the cluster version instead of inheriting the test plugin's default, which is unstated and below 1.35, and pins both sides of the boundary. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
Cozystack
Cozystack is a free platform and framework for building clouds.
Cozystack is a CNCF Sandbox Level Project that was originally built and sponsored by Ænix.
With Cozystack, you can transform a bunch of servers into an intelligent system with a simple REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers, HTTP caching services, and other services with ease.
Use Cozystack to build your own cloud or provide a cost-effective development environment.
Use-Cases
-
Using Cozystack to build a public cloud
You can use Cozystack as a backend for a public cloud -
Using Cozystack to build a private cloud
You can use Cozystack as a platform to build a private cloud powered by Infrastructure-as-Code approach -
Using Cozystack as a Kubernetes distribution
You can use Cozystack as a Kubernetes distribution for Bare Metal
Documentation
The documentation is located on the cozystack.io website.
Read the Getting Started section for a quick start.
If you encounter any difficulties, start with the troubleshooting guide and work your way through the process that we've outlined.
Versioning
Versioning adheres to the Semantic Versioning principles.
A full list of the available releases is available in the GitHub repository's Release section.
Contributions
Contributions are highly appreciated and very welcomed!
In case of bugs, please check if the issue has already been opened by checking the GitHub Issues section. If it isn't, you can open a new one. A detailed report will help us replicate it, assess it, and work on a fix.
You can express your intention to on the fix on your own. Commits are used to generate the changelog, and their author will be referenced in it.
If you have a concrete feature request, open an issue. For a cross-cutting or architectural change, open a design proposal in the community repo. For questions or early ideas, use GitHub Discussions. See CONTRIBUTING.md for the full routing.
Community
You are welcome to join our Telegram group and come to our weekly community meetings. Add them to your Google Calendar or iCal for convenience.
License
Cozystack is licensed under Apache 2.0.
The code is provided as-is with no warranties.
Commercial Support
A list of companies providing commercial support for this project can be found on official site.