Runtime: metrics view refer model connector

[k-anshul]

closes #5085

[begelundmuller]

The change works but conceptually speaking I am not sure of it.
We are changing the spec during reconcile which is something we haven't done before.
Also considered storing this in mv's state but technically speaking the model connector is a spec attribute.

Yeah editing the current resource's spec is something we want to be careful with. In this particular case, I think one of these options would be preferable:

1. (Simple and mostly correct option) Apply this PR to the mv.State.ValidSpec instead. It's used everywhere to actually render/query the metrics view.
2. (Complex but maybe more correct option) If model: is set in the YAML, capture it as a separate property in the spec (e.g. Spec.Model instead of Spec.Table). Then at query time, if the metrics view is based on a model, look it up to find the underlying connector+table to query.

[k-anshul]

(Simple and mostly correct option) Apply this PR to the mv.State.ValidSpec instead. It's used everywhere to actually render/query the metrics view.

So mv.Spec is what is being set to mv.State.ValidSpec so setting one or other should be equivalent?

(Complex but maybe more correct option) If model: is set in the YAML, capture it as a separate property in the spec (e.g. Spec.Model instead of Spec.Table). Then at query time, if the metrics view is based on a model, look it up to find the underlying connector+table to query.

I thought about it but not sure if we should worry about the underlying model being changed and metricsview not reconciled yet leading to inconsistencies.

[begelundmuller]

So mv.Spec is what is being set to mv.State.ValidSpec so setting one or other should be equivalent?

The ValidSpec is only updated if the Spec passes validation, otherwise it stays as the previous correct spec (only when StageChanges is true). In general, the idea is that a resource's "spec" is its desired state, and the "state" represents its actual state. So a creator (usually the YAML parser) will emit a spec, then the reconciler will update the state based on the spec, and then consumers should only consume from the state.

So I think for this PR we could extend this idea and say that the ValidSpec is not just a validated version of the spec, but a validated and enriched version of the spec.

[k-anshul]

The ValidSpec is only updated if the Spec passes validation, otherwise it stays as the previous correct spec (only when StageChanges is true). In general, the idea is that a resource's "spec" is its desired state, and the "state" represents its actual state. So a creator (usually the YAML parser) will emit a spec, then the reconciler will update the state based on the spec, and then consumers should only consume from the state.

So I think for this PR we could extend this idea and say that the ValidSpec is not just a validated version of the spec, but a validated and enriched version of the spec.

Sure. Sounds good.