Bug: Bundle image source should use ext.Spec.InstallNamespace, not systemNamespace

[joelanford]

See:

operator-controller/cmd/manager/main.go

Line 180 in f301f55

unpacker, err := source.NewDefaultUnpacker(mgr, systemNamespace, filepath.Join(cachePath, "unpack"), (*x509.CertPool)(nil))

This likely means a slight refactoring of the ImageRegistry implementation.

Related: it probably makes sense to stop using the composite unpacker and instead just use ImageRegistry directly.

[LalatenduMohanty]

/assign

[m1kola]

ImageRegistry is now being used, but it looks like we still need to fix AuthNamespace:

operator-controller/cmd/manager/main.go

Lines 197 to 202 in cf8b866

	unpacker := &source.ImageRegistry{
	BaseCachePath: filepath.Join(cachePath, "unpack"),
	// TODO: This needs to be derived per extension via ext.Spec.InstallNamespace
	AuthNamespace: systemNamespace,
	CertPoolWatcher: certPoolWatcher,
	}

[m1kola]

This namespace is only used when there is image pull secret specified and we currently do not specify it. So as far as I understand - this does not affect anything at the moment. @joelanford or am I missing something?

If we set AuthNamespace to ext.Spec.InstallNamespace this will mean that we will have to create a pull secret for image registry in the ext.Spec.InstallNamespace. Is this what we want to achieve? Oh, and we will also have to have a pull secret support (has to be in line with #1015, I suspect).

[joelanford]

The original idea was that a user would be able to specify an image pull secret on the ClusterExtension object. We don't have that field on our API, which explains why we don't plumb it through to the library.

Perhaps for now, in order to reduce the likelihood of the current unused setup being cargo-culted in the future, we should strip out the unused plumbing and internal API fields (that we control) that accept image pull secret configuration?