doc/user/olm-catalog/generating-a-csv.md: update config file paths and add notes on flags

Author: estroz

doc/user/olm-catalog/generating-a-csv.md

@@ -17,23 +17,23 @@ Operator SDK projects have an expected [project layout][doc-project-layout]. In
 
 `gen-csv` reads these files and adds their data to a CSV in an alternate form.
 
-By default, a `deploy/olm-catalog/csv-config.yaml` file is generated when `gen-csv` is first run. The defaults written in the following fields contain paths to the aforementioned files. From the [design doc][doc-csv-design]:
+By setting `--write-config`, a default `deploy/olm-catalog/csv-config.yaml` file is generated when `gen-csv` is run; setting `--csv-confg=<path>` will write a default config file to `path` instead. The defaults written in the following fields contain paths to the aforementioned files:
 
->Users can configure CSV composition by populating several fields in the file `deploy/olm-catalog/csv-config.yaml`:
->
->- `crd-cr-path-list`: (string(, string)\*) a list of CRD and CR manifest file/directory paths. Defaults to `[deploy/crds]`.
->- `operator-path`: (string) the operator resource manifest file path. Defaults to `deploy/operator.yaml`.
->- `rbac-path-list`: (string(, string)\*) a list of RBAC role manifest file paths. Defaults to `[deploy/role.yaml]`.
+- `crd-cr-paths`: string , { string } - a list of CRD and CR manifest file/directory paths. Defaults to `[deploy/crds]`.
+- `operator-path`: string - the operator `Deployment` manifest file path. Defaults to `deploy/operator.yaml`.
+- `role-path`: string - the RBAC `Role` manifest file path. Defaults to `deploy/role.yaml`.
 
-Fields in this config file can be modified to point towards alternate manifest locations. For example, if I have one set of production CR/CRD manifests under `deploy/crds/production`, and a set of test manifests under `deploy/crds/test`, and I only want to include production manifests in my CSV, I can set `crd-cr-path-list: [deploy/crds/production]`. `gen-csv` will then ignore `deploy/crds/test` when getting CR/CRD data.
+**Note**: The [design doc][doc-csv-design] has outdated field information which should not be referenced.
+
+Fields in this config file can be modified to point towards alternate manifest locations. For example, if I have one set of production CR/CRD manifests under `deploy/crds/production`, and a set of test manifests under `deploy/crds/test`, and I only want to include production manifests in my CSV, I can set `crd-cr-paths: [deploy/crds/production]`. `gen-csv` will then ignore `deploy/crds/test` when getting CR/CRD data.
 
 ## Versioning
 
 CSV's are versioned in path, file name, and in their `metadata.name` field. For example, running `operator-sdk olm-catalog gen-csv --csv-version 0.0.1` will generate a CSV at `deploy/olm-catalog/<operator-name>/0.0.1/<operator-name>.v0.0.1.clusterserviceversion.yaml`. A versioned directory such as `deploy/olm-catalog/<operator-name>/0.0.1` is known as a [*bundle*][doc-bundle]. Versions allow the OLM to upgrade or downgrade your Operator at runtime, i.e. in a cluster. A valid semantic version is required.
 
 `gen-csv` allows you to upgrade your CSV using the `--from-version` flag. If you have an existing CSV with version `0.0.1` and want to write a new version `0.0.2`, you can run `operator-sdk olm-catalog gen-csv --csv-version 0.0.2 --from-version 0.0.1`. This will write a new CSV manifest to `deploy/olm-catalog/<operator-name>/0.0.2/<operator-name>.v0.0.2.clusterserviceversion.yaml` containing user-defined data from `0.0.1` and any modifications you've made to `roles.yaml`, `operator.yaml`, CR's, or CRD's.
 
-The SDK can manage CRD's in your Operator bundle as well. You can pass the `--update-crds` flag to `gen-csv` to add or update your CRD's in your bundle by copying manifests pointed to by `crd-cr-path-list` in your config. CRD's in a bundle are not updated by default.
+The SDK can manage CRD's in your Operator bundle as well. You can pass the `--update-crds` flag to `gen-csv` to add or update your CRD's in your bundle by copying manifests pointed to by `crd-cr-paths` in your config. CRD's in a bundle are not updated by default.
 
 ## First Generation
 
@@ -89,7 +89,7 @@ Required:
 * `spec.labels`: (user) a list of `key:value` pairs to be used by Operator internals.
 * `spec.version`: semantic version of the Operator, ex. `0.1.1`.
 * `spec.installModes`: what mode of [installation namespacing][install-modes] OLM should use. Currently all but `MultiNamespace` are supported by SDK Operators.
-* `spec.customresourcedefinitions`: any CRD's the Operator uses. This field will be filled by the SDK if any CRD manifests pointed to by `crd-cr-path-list` in your config.
+* `spec.customresourcedefinitions`: any CRD's the Operator uses. This field will be filled by the SDK if any CRD manifests pointed to by `crd-cr-paths` in your config.
   * `description`: description of the CRD.
   * `resources`: any Kubernetes resources used by the CRD, ex. `Pod`'s and `ConfigMap`'s.
   * `specDescriptors`: UI hints for inputs and outputs of the Operator's spec.