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

[camilamacedo86]

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]

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]

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]

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

[estroz]

@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]

@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]

@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]

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

[camilamacedo86]

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.