Question: optional dependency

[pierreozoux]

Problem space

I want to start to work on a Nextcloud operator. This is an opensource PHP app that is an alternative to Gdrive.
It can work standalone (with SQLite) or work with Redis, S3, and Postgres to make it able to scale.

I want to make this operator as reusable as possible. Just speaking about redis (the same will apply to other dependency), I can see 3 scenarios:

1. The user doesn't specify any redis, and the app will not use any redis
2. The cluster provides a redis operator, then the Nextcloud operator will leverage that and create an instance for itself and configure the application to use it
3. The user provides a redis endpoint, the Nextcloud operator will leverage that and configure the app to use it.

Solution space

How can I say that there is an optional dependency on the Redis operator?
Do you have any advice on this setup?
Do you have libraries to build such logic ? If not where is the most appropriate place for such opensource library?

Thanks for your help!

[ron1]

Suggest you ask a question like this one in the Operator Framework Google Groups forum: https://groups.google.com/forum/#!forum/operator-framework.

[ecordell]

This is a good question -

The answer is that we don't really support modeling optional / weak dependencies with OLM.

But you can publish an operator that doesn't list an explicit requirement on another operator, and just explain via docs that you fill in the operator of your choice (a good example is plugging a db connection string into a CR).

Leaving this open to track the desire to model a weak dependency / suggest optional dependencies to install.

[jpkrohling]

Just wanted to share that we could make use of something like this in the Jaeger Operator as well. In our case, we may make use of the Elasticsearch and/or Strimzi Operators to automatically provision ES and Kafka clusters. To be clear: we don't require any of them to operate a Jaeger instance, but if those exist, we would unlock extra features.

The UI could show users that our Operator "works best" when those extra operators are available.

[njhale]

The UI could show users that our Operator "works best" when those extra operators are available.

@jpkrohling, @pierreozoux AFAICT, these weak dependencies would be purely informational and OLM wouldn't do any work based on them -- given that, I don't think they should be a spec field on APIs consumed by OLM for dependency resolution (e.g. CSV, Subscription, InstallPlan).

Do you have any advice on this setup?

Many operators wait for their APIs to be present in discovery before attempting to reconcile. I believe most client-go SharedIndexInformer implementations contain this logic as part of their HasSynced method. If you find this isn't the case, you can always watch/poll discovery explicitly. OLM does this to detect and use OpenShift's Operator API when present.

[jpkrohling]

these weak dependencies would be purely informational and OLM wouldn't do any work based on them

I beg to differ. If OLM knew about those dependencies, it could at least suggest to users that the operator they are installing would be improved if this other operator is installed first.

Many operators wait for their APIs to be present in discovery before attempting to reconcile

At least for the Jaeger Operator, we auto-adjust from time to time and can use new features as they become available. This issue really is about the user experience, IMO.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rcernich]

Just wanted to add to what @jpkrohling was saying... Having something like this in the spec would allow customization of the install UI, e.g. in Maistra, we could disable controls to enable tracing if Jaeger is not installed. While documenting usage is helpful, nobody reads docs.

FWIW, it looks like we're going to have to be disabling dependencies altogether, as having them seems to prevent independent upgrades of the dependencies (conflicting crd owner....).

[IBMRob]

This is something that we (IBM App Connect) were looking for recently. We wanted to support an optional dependency such that we could allow users to either install just our operator OR install our operator and another operator which provided a common set of logging/metrics/licensing applications.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.