Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Operator bundle resource descriptions should come from golang doc comments #1416

Closed
babbageclunk opened this issue Apr 21, 2021 · 9 comments
Closed
Assignees
Labels
blocked 🚧 Blocked by external factors

Comments

@babbageclunk
Copy link
Member

babbageclunk commented Apr 21, 2021

Describe the current behavior
At the moment the descriptions of the resources are in the template ClusterServiceVersion document config/operator-bundle/bases/azure-service-operator.clusterserviceversion.yaml (under .spec.customresourcedefinitions.owned). That means that if we add a resource but forget to add it to the yaml, it won't have any description in the Openshift resource UI.

Describe the improvement
We should populate that section of the CSV from the doc comments on the Go resource types.

  • The existing doc comments aren't great, they should be replaced with the ones from the CSV.
  • Add another build target depending on manifests that collects those up and writes them into a generated CSV yaml file in config/operator-bundle-populated/bases. (controller-gen puts the doc comments into each CRD yaml at .spec.validation.openAPIV3Schema.description .)
  • Change generate-operator-bundle to use that generated yaml as the base rather than the existing template one.
@babbageclunk
Copy link
Member Author

From discussion on #1410

@matthchr
Copy link
Member

The operatorhub CSV (Cluster Service Version) is a document that describes what the operatorhub bundle output looks like. Right now this file is handcrafted for ASO v1. For ASOv2, we would like to autogenerate this file so that we can pull the Resource descriptions from the Go types. This would probably be similar to the gen-kustomize target - possibly a new mode called gen-operatorhubmanifest or something.

@sakthi-vetrivel
Copy link

@babbageclunk should we push to next milestone?

@theunrepentantgeek
Copy link
Member

theunrepentantgeek commented Mar 15, 2022

Confirmed with offline discussion: this is still needed and should be done at the same time as #1967.

@matthchr matthchr modified the milestones: v2.0.0-beta.1, v2.0.0-beta.2 Jun 10, 2022
@matthchr
Copy link
Member

matthchr commented Oct 3, 2022

Status is still the same as above: Waiting on #1967

@matthchr
Copy link
Member

Status is still the same as above: Waiting on #1967

@matthchr matthchr modified the milestones: v2.2.0, v2.1.0 Apr 17, 2023
@matthchr matthchr modified the milestones: v2.1.0, v2.2.0 May 30, 2023
@matthchr
Copy link
Member

matthchr commented Nov 7, 2023

Still waiting on #1967

@theunrepentantgeek theunrepentantgeek modified the milestones: v2.6.0, v2.7.0 Dec 11, 2023
@matthchr matthchr removed this from the v2.7.0 milestone Feb 22, 2024
@matthchr
Copy link
Member

Still waiting on #1967

@matthchr matthchr added the blocked 🚧 Blocked by external factors label Mar 11, 2024
@matthchr
Copy link
Member

Closing in favor of tracking operator bundle stuff via #1967

@github-project-automation github-project-automation bot moved this from Backlog to Recently Completed in Azure Service Operator Roadmap Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked 🚧 Blocked by external factors
Projects
Development

No branches or pull requests

4 participants