[run bundle] Implement IndexImageCatalogCreator - create grpc catalog source

[rashmigottipati]

Description of the change:

• Create GRPC CatalogSource, pointing to the registry pod address (pointing to .:50051).
• Update catalog source with source type, address and annotations
• Verify that catalog source connection is ready

Motivation for the change:

This is one of the building blocks for implementing run bundle and run bundle-upgrade commands.
Links to enhancement proposals:
https://github.com/operator-framework/enhancements/blob/master/enhancements/run-bundle.md

[estroz]

The setup of this CatalogSource seems really weird to me. We're calling Init(internal.RegistryPod), but RegistryPod should be initialized by its own init method. We're also now exporting Pod, which shouldn't be since it is an internal concept.

How about doing something like what exists for packageManifestsManager, which will construct a CatalogSource in its run() method:

type BundleCmd struct {
	// Flag fields
}

type bundleManager struct {
	*operatorManager

	version     	  string
	resourceNamespace string // Where to create OLM resources
	operatorNamespace string
	bundle      	  *apimanifests.Bundle
	registryPod 	  *internalregistry.RegistryPod
	objects			  []unstructured.Unstructured // Resources to create
	client 			  olmclient.Client
	// Other required fields
}

func (c *BundleCmd) newManager() (m *bundleManager, err error) {
	// Check and parse flag values, other init stuff
	...
	m.registryPod, err = internalregistry.NewRegistryPod(...)
	if err != nil {
		return nil, err
	}
	...
}

func (m *bundleManager) run(ctx context.Context) (err error) {
	// Create registry pod and other resources
	...
	registryGRPCAddr := internalregistry.GetRegistryServiceAddr(
		registryPod.GetPodName(),
		m.resourceNamespace)
	catsrc := newCatalogSource(registryPod.GetPodName(),
		m.operatorNamespace,
		withGRPC(registryGRPCAddr))
	m.objects = append(m.objects, catsrc)

	...
	return m.client.DoCreate(m.objects...)
}

[joelanford]

@estroz @rashmigottipati I was hoping we could refactor and reuse even more of what already exists for run packagemanifests.

Will there be any difference whatsoever between run packagemanifests and run bundle for anything after the creation of the pod that runs the ephemeral index?

I'm wondering if the CLIs for run bundle and run packagemanifest can even reuse the same struct with an interface field for creating the index pod. Then run packagemanifest can plug in its implementation and run bundle can plug in its. All other setup would be the same right?

[estroz]

@joelanford other than pod creation and some catalogsource/subscription data, they’re effectively the same. The main difference is having a slice of bundles and a package manifest vs one bundle and metadata, so just the underlying implementations of the interface you suggest.

[joelanford]

@estroz What would be different in the catalog source and subscription between the two?

In both cases, aren't we pointing the catalog source to a GRPC port on a pod and creating a subscription with the package name, and catalog source name/namespace?

[rashmigottipati]

@joelanford

@estroz What would be different in the catalog source and subscription between the two?

In both cases, aren't we pointing the catalog source to a GRPC port on a pod and creating a subscription with the package name, and catalog source name/namespace?

I think that's right. Creation of catalog source is same for both run bundle and run packagemanifest.
For creating a subscription, run packagemanifest sets the catalog name and namespace, target package, channel, and starting CSV. It uses the CSV name to set the subscription name.

[rashmigottipati]

@joelanford @estroz

Thanks for the inputs. Totally agree with refactoring and reusing more of the existing logic in packagemanifests. Since jira tasks for run bundle have create grpc catalog source and create subscription logic, I was treating them as individual building blocks first, so started writing separate logic and adding unit tests for these smaller portions with the intention to refactor later to suit the packagemanifests style. However, as I'm working on subscription logic, it occurred to me that all of these custom resources (i.e. catalog source and subscription) could be created at once (similar to run method in packagemanifests) after initializing the registry pod.

Thinking about what would be the best approach to take:
If we decide to reuse packagemanifests code by using the same struct with an interface field for creating the index pod, it's probably better to do it by breaking down into smaller PRs.
For the purpose of this PR, would it be reasonable to do something like what exists for packageManifestsManager, which will construct a CatalogSource in its run() method as @estroz suggested, and in the upcoming PRs, refactor and reuse the existing packagemanifests logic by adding an interface field to the same struct.

Any suggestions?

[rashmigottipati]

Added functionality to create the catalog source based on new design, @joelanford @estroz @jmrodri please take a look

[jmrodri]

/lgtm

The changes in this PR supercede the comments from Eric's review. Dismissing this review to keep this moving.

[jmrodri]

Also, we're postponing adding tests for next sprint.