Possibility of an upgrade from one package to another

[m1kola]

I think there is a case when there are packages package1 and package2 with bundles which share the same bundle image. I think two following pieces of code (they work together) might allow upgrading from package1 to package2.

operator-controller/internal/resolution/variablesources/bundle_deployment.go

Lines 43 to 53 in 7161a7b

	if sourceImage != nil && sourceImage.Ref != "" {
	if processed.Has(sourceImage.Ref) {
	continue
	}
	processed.Insert(sourceImage.Ref)
	ips, err := NewInstalledPackageVariableSource(o.catalogClient, bundleDeployment.Spec.Template.Spec.Source.Image.Ref)
	if err != nil {
	return nil, err
	}
	variableSources = append(variableSources, ips)
	}

operator-controller/internal/resolution/variablesources/installed_package.go

Lines 31 to 43 in 7161a7b

	// find corresponding bundle for the installed content
	resultSet := catalogfilter.Filter(allBundles, catalogfilter.WithBundleImage(r.bundleImage))
	if len(resultSet) == 0 {
	return nil, r.notFoundError()
	}
	// TODO: fast follow - we should check whether we are already supporting the channel attribute in the operator spec.
	// if so, we should take the value from spec of the operator CR in the owner ref of the bundle deployment.
	// If that channel is set, we need to update the filter above to filter by channel as well.
	sort.SliceStable(resultSet, func(i, j int) bool {
	return catalogsort.ByVersion(resultSet[i], resultSet[j])
	})
	installedBundle := resultSet[0]

E.g. when catalogs (single catalog or two different catalogs) have something like this:

package1 bundles:

• image:tag1 - version 1.0.0

package2 bundles:

• image:tag1 - version 1.0.0
• image:tag2 - version 1.0.1

In this case, I think, when we install package1 at version 1.0.0 and then upgrade - our installed bundle might end up being the one from package2 since we search bundes by image references. And installed bundle is driving successors.

I looked into how to mitigate this in #442 but it didn't feel like the right solutiion.

[joelanford]

In this case, I think, when we install package1 at version 1.0.0 and then upgrade - our installed bundle might end up being the one from package2 since we search bundes by image references. And installed bundle is driving successors.

This should not be possible if we are filtering bundles by package name based on Operator.spec.packageName.

[m1kola]

This should not be possible if we are filtering bundles by package name based on Operator.spec.packageName.

We don't seem to do that: I can only see filtering by bundle image here. And we filter successors by package name, but we rely on installed package name.

I think as part of work for #449 I will have to have both Operator and BundleDeployment available in the relevant code (so we can switch between enforcing and ignoring upgrade edge constraints). And it will enable us filtering by package name specified on the Operator spec.

[joelanford]

Yeah, I think I started to put the pieces together as I reviewed #460, and I left a few comments in this area:

• 🌱 Reduce number of variable sources #460 (comment)
• 🌱 Reduce number of variable sources #460 (comment)