Fix image component handling, honoring Installation spec

[petrutlucian94]

components.GetReference currently ignores the image prefix and path specified in the "Installation" spec.

It makes a copy of the image component, appends the configured image path and prefix but then it uses the original component image when looping over the image set.

The fix is trivial, we just have to use the modified image string.

Description

For PR author

• Tests for change.
• If changing pkg/apis/, run make gen-files
• If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

• Milestone set according to targeted release.
• Appropriate labels:
  • kind/bug if this is a bugfix.
  • kind/enhancement if this is a a new feature.
  • enterprise if this PR applies to Calico Enterprise only.

[CLAassistant]

All committers have signed the CLA.

[petrutlucian94]

Looks like there is another blocker that prevents us from using custom built images. We could pass in the install spec (or just the image path/prefix) and apply them just like GetReference does.

operator/pkg/controller/utils/imageset/imageset.go

Line 141 in ec635bf

func ValidateImageSet(is *operator.ImageSet) error {

"ImageSet calico-v3.28.0: unexpected images: petrutlucian94/calico-node, petrutlucian94/calico-cni, petrutlucian94/calico-typha, petrutlucian94/calico-kube-controllers, petrutlucian94/calico-tigera-operator, petrutlucian94/calico-csi, petrutlucian94/calico-apiserver, petrutlucian94/calico-ctl, petrutlucian94/calico-pod2daemon-flexvol, petrutlucian94/calico-key-cert-provisioner",

[tmjd]

For an ImageSet we need a reference to match an ImageSet Digest to the image it will be used with. I would suggest we document that the "Image" value in the ImageSet is the original (unmodified) image name and ignores any registry, path, or prefix changes.
This would ensure there is no change in behavior for users that have figured out this is the way the ImageSets work.