[Question]operator-sdk support generate dependencies ?

[whg517]

Type of question

General operator-related help

Question

What did you do?

Hi, I am developing operator based on OLM. Now I need to generate the dependencies.yaml file in the bundle/metadata from the Dependency Resolution document and Operator Bundle in OLM and define the operator dependency. But I found nothing describing how to generate dependencies using operator. As I understand it, I need to manually write a complete dependency file in the metadata directory. The bundle directory is automatically generated by operator-sdk generate bundle, so I don't think it makes sense.

I wonder if there is another way to configure operator's dependencies. Or there is no documentation for a complete example

What did you expect to see?

Do I want someone to tell me if a dependency file dependencies.yaml for an operator is manually created in the bundle/metadata directory? Or it's a creation that I can manifest in the config directory like config/manifests.

What did you see instead? Under which circumstances?

no desc

Environment

Operator type:golang

Kubernetes cluster type:k3s

$ operator-sdk version

operator-sdk version: "v1.31.0", commit: "e67da35ef4fff3e471a208904b2a142b27ae32b1", kubernetes version: "v1.26.0", go version: "go1.20.6", GOOS: "darwin", GOARCH: "arm64"

$ go version (if language is Go)

go version go1.20.7 darwin/arm64

$ kubectl version

Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.4+k3s1", GitCommit:"36645e7311e9bdbbf2adb79ecd8bd68556bc86f6", GitTreeState:"clean", BuildDate:"2023-07-28T09:46:05Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/arm64"}

Additional context

[varshaprasad96]

@whg517 Operator-sdk currently doesn't support generating dependencies.yaml file with the operator bundle. @grokspawn is this something operator authors would benefit from if scaffolded by SDK?

[acornett21]

I'll add that if a dependency.yaml is added to bundle/metadata and operator-sdk genereate bundle is ran, operator-sdk does not overwrite this file. Since dependencies are so infrequently used, I'm not sure it would add alot of value if we were to scaffold that file. Also, the formate of the file would change depending on if the operator author was trying to tie to a specific version of an operator or a specific version of a CRD, so from operator-sdk's prospective, we would not know which type/formate of file to scaffold.

[whg517]

@acornett21 I understand what you mean, but I would still like to see better support or practical guidance on dependency.

Thanks to olm's strong dependency management capabilities, we can flexibly control the version planning and compatibility of each component. I will continue to delve into the use of olm dependencies and try to shape some of our production practices.

I also hope that others with better ideas will share your experiences with me. thank you

[varshaprasad96]

I would still like to see better support or practical guidance on dependency

Could you elaborate more what your use case is?

We would like to keep this issue open in case there are more asks from the community to include dependency.yaml while generating bundle. Adding this to the backlog for now.

[whg517]

Background

Our team is designing and developing a cloud-native and plug-in concept to solve problems in the field of data processing.

We wanted to use OLM to solve our problem of managing and maintaining data processing components on the cloud native. In the data processing area, teams need to manage and maintain a set of data processing component services. For example, postgres minio provides the underlying storage, hive-metastore kafka metadata and message storage, and spark flink provides the computing power. We are developing operators based on OLM and using OLM's lifecycle management capabilities and dependency management capabilities to solve the installation, upgrade, uninstall and maintenance of these components.

On the upper layer of operator, a console system enables users to flexibly and conveniently manage and maintain component services through the Web, and provides observability.

That's what our team is doing.

Desc

We are currently having some problems developing operators using OLM, and we are actively looking for scenarios and best practices for developing operators, as we maintain a set of operators and write the logic according to the unified development specification.

Since this is a dependency issue, I'll just describe some of the problems we encountered when using dependencies and how we're working around them.

Q&A

Q: Dependency files cannot be automatically generated using operator-sdk

Desc: As far as I know, a project generated by operator-sdk, when generating bundles, will have a bundle directory in the project directory and contain the corresponding yaml file generated, so the bundle directory is dynamic and should not be tracked by git of the project. But in order to keep the dependency files, this directory needs to be created.

A: The way I do it now is that git keeps track of the dependent files in the bundle directory, but doesn't keep track of the other files in the bundle directory

---

I still have some questions about using catalog. I feel that it is inappropriate to discuss this issue below, so I will not discuss it for the time being.

[acornett21]

A: The way I do it now is that git keeps track of the dependent files in the bundle directory, but doesn't keep track of the other files in the bundle directory

This is how I personally treat the dependency file, since the dependencies needed are likely to not change for one release to another release of the operator. Also this is how most Independent Software Vendors (ISV's) treat this file as well.

I still have some questions about using catalog. I feel that it is inappropriate to discuss this issue below, so I will not discuss it for the time being.

There is a google group for Operator Framework, feel free to join and ask any/all of your questions there. This is probably a better place for general or best practices questions, as the group spans a wider audience then a given GH issue can.

[openshift-bot]

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

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.