openshift / cluster-olm-operator

OpenShift operator that manages the Operator Lifecycle Manager components

cluster-olm-operator

Operator that manages the lifecycle of the Operator Lifecycle Manager (OLM) components.

The repo is for a downstream specific component

It exists as a way for us to facilitate two things:

1. To turn off and on the feature flags for olm v1 so we could ship it in the openshift payload without it being turned on by default
2. To handle the clusterstatus resource for the v1 components

Because OCP has an API that's part of the cluster-version-operator, that isn't in plain kubernetes, that tracks the state of all the OCP components, and if you're in the payload you are required to write status to it

cluster-olm-operator's Issues

Improve deployment controller name generation

In #25, I had to keep the namespace of the object out of the controller name to make the controller name generated for the operator controller deployment fit within the character count for finalizer name length

Without namespace, there's a possibility of a component putting a deployment with the same name in two namespaces, which would conflict.

I was hoping to make this somewhat human-friendly, but that seems iffy. A few other options are:

• Just always use a numeric index
• Try the friendly name, but if it is too long, fallback to something else.

I'm also wondering what happens if these names change over time what if a previous version of cluster-olm-operator adds some conditions based on these names, then we change the names? I'm not sure anything knows to clean up the old names. This isn't really a new problem, but generating a name seems like it changes things from theoretical problem to likely problem.

Thoughts?

Originally posted by @joelanford in #25 (comment)

StaticResourcesController does not delete static resources when "cluster" olm object is deleted.

Not sure if this is intentional in the StaticResourceController logic, or if I've coded our controller incorrectly, but I am not seeing the resources managed by static resource controllers being deleted when the "cluster" olm object is deleted.

I don't think this is a blocker because:

1. We're in TechPreview and don't expect the "cluster" olm object to be deleted in the first place
2. NOT deleting the static resources may be intentional to avoid data loss. Our CRDs are managed by the static resource controllers, so it may actually be desirable to keep those around even when the "cluster" olm object is gone.
3. Re-creating the "cluster" olm object after a deletion does not seem to cause any problems. The controller finds the existing objects and resumes managing them.

One slightly undesirable thing does happen though. The cluster-olm-operator logs are spammed during resyncs with:

E0626 10:34:38.586824   98752 base_controller.go:268] RukpakStaticResources reconciliation failed: olm.operator.openshift.io "cluster" not found
E0626 10:34:38.586845   98752 base_controller.go:268] CatalogdStaticResources reconciliation failed: olm.operator.openshift.io "cluster" not found
E0626 10:34:38.587920   98752 base_controller.go:268] OperatorControllerStaticResources reconciliation failed: olm.operator.openshift.io "cluster" not found

TODO: lookup the actual version (rather than hardcoding 0.0.1)

cluster-olm-operator/cmd/cluster-olm-operator/main.go

Lines 49 to 50 in 8a7f597

	// TODO: lookup the actual version
	version.Info{Major: "0", Minor: "0", GitVersion: "0.0.1"},

Future Release Branches Frozen For Merging | branch:release-4.18 branch:release-4.19

The following branches are being fast-forwarded from the current development branch (main) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.18
• release-4.19

For more information, see the branching documentation.