operator-lib

operator-lib copied to clipboard

Bug Report

What did you do? Created a wrapper function in our operator code that finds the name of the associated OLM OperatorCondition and then uses the InClusterFactory API to set the upgradeable condition. Then we started writing tests to test this function.

What did you expect to see? Tests to pass or fail depending on the correct writing of the wrapper function and calling the correct InClusterFactory and Condition code.

What did you see instead? Under which circumstances? The error: get operator condition namespace: namespace not found for current environment. Since the unit tests are using a fake runtime client and running locally, this was to be expected since InClusterFactory.GetNamespacedName() calls utils.GetOperatorNamespace(). However, what was unexpected was in our tests there is no way to override this since:

• utils package is internal so private
• readNamespace is private
• the library's own tests can override since they share the same package as readNamespace.

Environment

• operator-lib version: 0.9.x

• github.com/operator-framework/operator-lib v0.9.0

Possible Solutions

• make readNamespace public
• provide an interface to allow GetNamespacedName to be overridden
• allow the namespace to be injected into InClusterFactory (since the operator provides the namespace through request.namespace, it might be a nice alternative?)

Additional context Add any other context about the problem here.

Very similar to #50

The purpose of the PR (#58) that introduced the InClusterFactory is that you could substitute that out in your tests and use a separate implementation of conditions.Factory such that GetNamespacedName() can return whatever you need it to.

The purpose of the PR (#58) that introduced the InClusterFactory is that you could substitute that out in your tests and use a separate implementation of conditions.Factory such that GetNamespacedName() can return whatever you need it to.

I did try that earlier but found that condition type is also private -> https://github.com/operator-framework/operator-lib/blob/v0.9.x/conditions/factory.go#L49.

So am not sure how that would help. My interface would have to return a NewCondition of type Condition * but that would then require a re-implementation of Get and Set. Either way it would be a lot of work just to workaround for a unit test.

If it would help my code is located here:

• wrapper function -> https://github.com/phantomjinx/syndesis/blob/upgrade-cond-review/install/operator/pkg/syndesis/olm/operator_conditions.go#L116
• test function -> https://github.com/phantomjinx/syndesis/blob/upgrade-cond-review/install/operator/pkg/syndesis/olm/operator_conditions_test.go#L120

Yeah Condition is also an interface. Perhaps we need to implement a Factory and Condition that are more suitable for use in tests so that operator-lib users aren't all re-inventing the wheel when they need alternates.

However, I don't think we want to change anything about the functionality of the InClusterFactory because it is meant to work for in-cluster use cases only. Background here: https://github.com/operator-framework/operator-lib/issues/50#issuecomment-823539147

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

/lifecycle frozen

Perhaps we need to implement a Factory and Condition that are more suitable for use in tests so that operator-lib users aren't all re-inventing the wheel when they need alternates.

We'd be happy to accept a PR that adds MockFactory and MockCondition structs that implement these interfaces so that these can be subbed in during unit tests for fine-grained testing of the OperatorCondition feature.