https://github.com/openshift/release/pull/61726 merged and periodic-ci-openshift-hypershift-release-4.19-periodics-e2e-azure-kubevirt-ovn has been running for a week.

Our docs indicate we should observe for a sprint before making informing. That would mean we should look at merging https://github.com/openshift/release/pull/61709 around Mar. 20.

per slack thread

relevant jobs were renamed with the kubevirt-ovn convention in https://github.com/openshift/release/pull/62005

https://github.com/openshift/release/pull/61608 adds 4.19-deploy-azure-kubevirt-ovn job to informing status, for 4.19 only, as there is no real path for adding informing jobs in GA releases.

a followup https://github.com/openshift/release/pull/61726 adds an appropriately-named job for imminent consideration as informing.

The 4.19 job looks good, will 4.20 work when we branch automatically?

I can't tell that with 100% certainty, but most likely it would pass. Unless there will be something in OCP 4.20 that might break CNV and we'll see test failures. In such case, we'll triage and consider how to fix.

I also wonder what you want to get out of informing on older releases, you'd get the same impact by just being on a cron

The long term goal is to get them into blocking status, but for this we need to reach a near 100% pass rate for a long period of time. That way, if OCP will introduce code that breaks CNV, it will get more attention.

CNV/virt/kubevirt need to pick one naming convention for their jobs, all 3 are used interchangeablely.  Pick one and rename all the existing jobs to use it.

Not sure about the "virt" one, but the terms "cnv" and "kubevirt" are not entirely identical.

"cnv" means "OpenShift Virtualization", which is the whole product, while "kubevirt" refer to the core virtualization part (which is also the name of the upstream project). In terms of HyperShift providers, we use the term "kubevirt provider" to indicate we use cluster-api-provider-kubevirt to spin up guest clusters, and in the docs it is referred as the kubevirt platform

Similar to the comment I left on https://issues.redhat.com/browse/TRT-2013

The 4.19 job looks good, will 4.20 work when we branch automatically?

For the others, we generally don't take informers on older releases. Once you're informing on development releases, you could discuss with the errata reliability team (ERT) about trying to add signal to older releases (they own them) but I don't know of a case where we've done that in the past.  I also wonder what you want to get out of informing on older releases, you'd get the same impact by just being on a cron.  Informers aren't really monitored, and are just a stepping stone to blocking.

CNV/virt/kubevirt need to pick one naming convention for their jobs, all 3 are used interchangeablely.  Pick one and rename all the existing jobs to use it.