[HCO] New API suggestion

[Nahshon Unna Tsameret]

Hi all.

We are planning to introduce the new v1 API for the HyperConverged type in the next release of HCO (v1.18).

The enhancement proposal PR [1] is ready for review, and your comments are welcome.

Regards,

Nahshon

[1] https://github.com/kubevirt/hyperconverged-cluster-operator/pull/4018

[Nahshon Unna Tsameret]

No comment so far here.

Enhancement accepted.

We're merging the enhancement PR and starting the implementation.

[Itamar Holder]

Hey Nahshon!

As commented in the PR, since we plan to enable Kubevirt beta feature gates by default in v1.9, I think it is important that HCO will have an API to supply an arbitrary list of kubevirt FGs to disable in order to ensure downstream can disable these feature gates.

As we agreed offline, we’ll discuss this more thoroughly next week.

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/ca96f249-f8f4-4360-9390-16eb2f632ba7n%40googlegroups.com.

[Dan Kenigsberg]

On Thu, Feb 19, 2026 at 6:35 PM 'Itamar Holder' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

Hey Nahshon!

As commented in the PR, since we plan to enable Kubevirt beta feature gates by default in v1.9, I think it is important that HCO will have an API to supply an arbitrary list of kubevirt FGs to disable in order to ensure downstream can disable these feature gates.

As we agreed offline, we’ll discuss this more thoroughly next week.

Please share this publicly as I'm not sure I understand this. HCO is opinionated. It should enable/disable feature gates as it pleases. It does not follow that HCO must  expose an API with a lower level features. It smells like a violation of layering.

[Itamar Holder]

On Mon, 23 Feb 2026 at 09:40, Dan Kenigsberg <dan...@redhat.com> wrote:

On Thu, Feb 19, 2026 at 6:35 PM 'Itamar Holder' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

Hey Nahshon!

As commented in the PR, since we plan to enable Kubevirt beta feature gates by default in v1.9, I think it is important that HCO will have an API to supply an arbitrary list of kubevirt FGs to disable in order to ensure downstream can disable these feature gates.

As we agreed offline, we’ll discuss this more thoroughly next week.

Please share this publicly as I'm not sure I understand this.

Yes, of course. Even though we've discussed this a few times before, we haven't settled on the details yet.

The discussion and planning of this will obviously be made publicly.

I plan to bring this up soon, hoping to target this for v1.9.

 

HCO is opinionated. It should enable/disable feature gates as it pleases. It does not follow that HCO must  expose an API with a lower level features. It smells like a violation of layering.

As said, the plan for Kubevirt is to enable beta feature gates by default upstream.

However, downstream vendors that use HCO will probably want to disable these FGs in production (or at least most of them).

This is already possible today, but with a cumbersome, manual and error-prone process through JSON patches. My aim here is to ease Kubevirt's deployment in production environments by somehow configuring HCO to turn off non-GA FGs by default (or under some kind of a configuration).

[Dan Kenigsberg]

Sorry, but I do not follow. Why would we want HCO to leak an underlying API? What is the use case?

HCO exists for Downstreams. Downstream should bake the KubeVirt feature gates into HCO code. Clearly, HCO should *use* KubeVirt's FGs, but I don't see why it should blindly expose them all in its own API.

 

[Nahshon Unna Tsameret]

Thanks for the comments, but the adoption of the new KV feature gate implementation in HCO is not relevant to the new API. We'll need to fully design it, including API changes, if needed, elsewhere. And since it's for the next version of HCO, then if API changes will be required, we'll need the change in both API versions anyway.

[Itamar Holder]

Oh, got you, you mean that we can manage the FG disablement from within HCO without exposing any APIs. Yup, that's a possibility.

Either way, I'm not suggesting blindly exposing them all in the API. What I had in mind is a free-form map (or something similar) to control Kubevirt FGs. But managing it from HCO's code is definitely a valid alternative. These details haven't been settled yet.

I mainly wanted to raise attention to the need to disable non-GA FGs downstream by HCO rather than to suggest a concrete way of doing so.