Validation fails due to outdated schema (OCP version difference)

[tumido]

The thing we've been afraid of just happened.

Kubeval fails in operate-first/apps#2479 due to schema difference...

While master-standalone-strict/network-operator-v1.json doesn't list gatewayConfig as a valid property of .spec.defaultNetwork.ovnKubernetesConfig, this is totally acceptable in OCP 4.10:

How can we solve this? Track manifests per OCP version? Or order cluster artifacts in generate schemas job - so we store the latest schema versions rather than random one?

/cc @mimotej

[HumairAK]

not sure but can we add this resource to the skip resource list to unblock this pr while we figure out a long term solution ?

[mimotej]

@tumido
I think the simplest would be to run job over cluster which has latest manifests last (propably smaug?). Issue with this could be that there might be situation when schema is not backwards compatible. I am not sure how often that happens but there might be possibility.
Storing different versions comes with it's set of issues:

1. I am not aware of any way how to tell simply if there was added any kind of breaking change or if it was only change in wording in some description. That means we would have to propably track any change there happens
2. This is connected to the 1). We can't tell what version of manifest runs on the cluster that means we would have to run kubeval multiple times if it would fail. This would take a long time and also would be demanding on resources.
3. Repository size would propably go out of control pretty fast.

If we are going to go with storing latest schema version I think this could be done by simply removing job from matrix and putting it after the matrix job.

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[tumido]

/remove-lifecycle stale

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[sesheta]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten