Skip to content

Missing attributes in the file generated by "operator-sdk olm-catalog" #1259

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

Closed
camilamacedo86 opened this issue Mar 28, 2019 · 8 comments
Closed
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. olm-integration Issue relates to the OLM integration

Comments

@camilamacedo86
Copy link
Contributor

camilamacedo86 commented Mar 28, 2019

Bug Report

Missing attributes in the file generated by "operator-sdk olm-catalog"

What did you do?

  • Use the command operator-sdk olm-catalog to created the ClusterServiceVersion
    operator-sdk olm-catalog gen-csv --csv-version 0.0.1 --csv-config memcached-operator.0.0.1.clusterserviceversion.yaml

What did you expect to see?
When applying the resource by " kubectl apply -f ../0.0.1/memcached-operator.v0.0.1.clusterserviceversion.yaml" all worked well

What did you see instead? Under which circumstances?
The following attributes missing.

spec.customresourcedefinitions.owned.displayName in body is required
spec.customresourcedefinitions.owned.description in body is required

The same issue will be checked for the following attributes.

provider:
    name: Camila, Inc
  keywords:
  - memcached
  - app
  maintainers:
  - email: [email protected]
    name: Some Corp

Environment

  • operator-sdk version:
$ operator-sdk --version
operator-sdk version v0.5.0+git

Master Branch

  • Kubernetes version information:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-03-01T23:34:27Z", GoVersion:"go1.12", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-03-26T20:24:47Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
  • Kubernetes cluster kind: Minishift with OLM

  • Are you writing your operator in ansible, helm, or go?
    Go

Possible Solution
Just make the command add the missing values as I added them manually.

spec:
  apiservicedefinitions: {}
  customresourcedefinitions:
    owned:
    - kind: Memcached
      name: memcacheds.cache.example.com
      version: v1alpha1
      description: Operator Memcached Desc
      displayName: Memcached Operator

and

provider:
    name: Camila, Inc
  keywords:
  - memcached
  - app
  maintainers:
  - email: [email protected]
    name: Some Corp

Additional context
Add any other context about the problem here.

@lilic lilic added the olm-integration Issue relates to the OLM integration label Mar 29, 2019
@lilic
Copy link
Member

lilic commented Mar 29, 2019

Hello @camilamacedo86

spec.customresourcedefinitions.owned.displayName in body is required
spec.customresourcedefinitions.owned.description in body is required

Those you need to fill in yourself as a user. There is a docs PR to clarify this to users, along with a list of fields you need to input. https://github.com/operator-framework/operator-sdk/pull/1242/files#diff-e0a112b07230172e80465d88412384bdR84

@jcrossley3
Copy link
Contributor

I believe this issue is not about spec.displayName and spec.description which are filled in with placeholder text, but instead spec.customresourcedefinitions.owned.displayName and spec.customresourcedefinitions.owned.description which are not.

It's fine, though inconvenient, to expect the user to fill them in, but it'd be nice if the gen-csv task would at least warn you that they're required. It's not a great user experience otherwise.

@lilic
Copy link
Member

lilic commented Apr 24, 2019

@jcrossley3 thanks for the feedback, pinging @estroz as he mainly works on this.

@estroz
Copy link
Member

estroz commented Apr 24, 2019

@camilamacedo86 @jcrossley3 we're working on a PR (#1162) to infer data in spec.customresourcedefinitions.owned from a CRD's dir.

Side note: --csv-config takes a CSV config file as an argument and not a CSV. You don't need to set this flag if you're using defaults.

@jcrossley3
Copy link
Contributor

@estroz thank you, but it wasn't clear to me how to use that config file to preserve those entries. do you have an example?

@estroz
Copy link
Member

estroz commented Apr 24, 2019

@jcrossley3 by preserve you mean not overwrite what's already in the CSV? If so, #1162 intends to determine what to put in spec.customresourcedefinitions.owned using code annotations described in this user doc. The csv-config.yaml file is only intended to point to files used in CSV generation.

@openshift-bot
Copy link

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-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 24, 2019
@camilamacedo86
Copy link
Contributor Author

It can be closed.
I did the test with the version : v0.8.1, commit: 33b3bfe10176f8647f5354516fff29dea42b6342 and the same issue could no longer be faced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. olm-integration Issue relates to the OLM integration
Projects
None yet
Development

No branches or pull requests

6 participants