Skip to content

Support for optional @Dependent resources #2238

Closed
@Javatar81

Description

@Javatar81

In the current version JOSDK assumes when registering a dependent resource that it's managed dependent resource type (e.g. a ConfigMap or ServiceMonitor) is available and hence required for the operator. In most cases this holds true but for certain resource types (e.g. the ServiceMonitor) the dependency could be less strict when they are not available. The usual scenario with a required dependent looks like this:

  1. The ServiceMonitor CRD is not available in the cluster
  2. My operator defined a @Dependent managing the ServiceMonitor
  3. The operator expresses its requirement for the ServiceMonitor CRD via the ClusterServiceVersion.spec.customresourcedefinitions.required field
  4. If I install the operator with this requirement, the Prometheus operator will be installed, too.

So far so good, but how could I implement the following behavior:

  1. The ServiceMonitor CRD is not be available in the cluster
  2. My operator defined a @Dependent managing the ServiceMonitor
  3. The operator does NOT define a requirement for the ServiceMonitor CRD via the ClusterServiceVersion.spec.customresourcedefinitions.required field
  4. Without the requirement, the Prometheus operator will NOT be installed.
  5. The operator defines an activationCondition that checks whether ServiceMonitor API is available in the cluster
    6a. The operator does not fail but ignores that it is not able to reconcile the ServiceMonitor because it is just optional.
    6b. The user installs the ServiceMonitor manually because she wants to use it and because it is available now, the operator will reconcile the ServiceMonitor (activationCondition holds true)

I see this type of optional dependencies in many official OpenShift operators, e.g. the ServiceMesh operator that interacts with Kiali. Kiali is not in the ClusterServiceVersion.spec.customresourcedefinitions.required. It must be installed before the ServiceMesh operator is installed.

A potential solution could be to introduce a new attribute optional:

@Dependent(type = ServiceMonitorDependentResource.class, optional = true)

This attribute would add an activationCondition behind the scenes that checks for the API of the CRD and it would lead to omission of the CRD in the ClusterServiceVersion.spec.customresourcedefinitions.required array.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions