-
Notifications
You must be signed in to change notification settings - Fork 32
refine install and dependency docs #21
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: dmesser <dmesser@redhat.com>
a07b73c to
49e9171
Compare
Signed-off-by: dmesser <dmesser@redhat.com>
49e9171 to
06a8d68
Compare
Bowenislandsong
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great PR, Thank you for cleaning some of the stuff up. Just some nits.
| You can inspect your `Subscription` with `kubectl describe subs <name-of-your-subscription> -n <namespace>`. | ||
|
|
||
| ```yaml | ||
| k describe subs subs-to-my-operator -n olm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we want to say $ kubectl instead of k?
| In case multiple Operators serve a required API, rather than using the first match, OLM searches `CatalogSources` in a specific order. First is the same catalog that contains the Operator stating the dependency, followed by other catalogs in the same namespace as the required `Subscription` and then finally all remaining `CatalogSources` objects in other namespaces of the cluster. | ||
|
|
||
| If the required API cannot be resolved, OLM will not install operators that rely on that API. | ||
| If are required API cannot be resolved or found, OLM will not install operators that rely on that API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I don't understand why we changed the to are...
awgreene
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work @dmesser, a few comments but the suggested changes look great.
| # How do I install my operator with OLM? | ||
| # How do I install my operator with OLM? | ||
|
|
||
| [Once you've made your packaged operator available in a catalog](packaging-an-operator.md) it will appear in the `packagemanifest` list from which the Operators to install are selected. See [How do I list available Operators](list-available-operators.md#information-relevant-for-installation) how to retrieve the required information from the `PackageServer` in order start an installation of an Operator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following sentence does not read well:
See [How do I list available Operators] how to retrieve...
| $ kubectl describe packagemanifest my-operator | ||
| ``` | ||
|
|
||
| With this information a `Subscription` object can be created. This represents the intent to install an Operator from a particular catalog and keep it updated throughout the life cycle of the Operator via newly released version that got subsequently added to the referenced catalog. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend changing
This represents the intent to install an Operator from a particular catalog and keep it updated throughout the life cycle of the Operator via newly released version that got subsequently added to the referenced catalog.
to
A subscription represents the desire to install an Operator from a particular catalog and keep it updated as new versions are subsequently added to the referenced catalog.
or somethings along those lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe even
With this information, a
Subscriptionto an operator can be created.
instead of
With this information a
Subscriptionobject can be created.
And in @awgreene 's suggestion:
A subscription represents the desire to install an Operator from a particular catalog and keep it updated as new versions are subsequently added to the referenced catalog.
if we tweak it to
A subscription represents the desire to install an Operator from a particular catalog, and subscribe to updated version of the operators as they are subsequently added to the catalog.
then if could read like more of a user facing doc than dev facing doc.
| For example, if you want to install an operator named `my-operator`, from a catalog named `my-catalog` that is in the namespace `olm`, and you want to subscribe to the channel `stable`, your subscription yaml would look like this: | ||
| ``` | ||
| The `spec.channel` property can also be omitted in which case the default channel will be picked. Optionally you can also define `spec.startingCSV` to denote that you want to install a specific version of your Operator and not the latest. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we highlight behavior when specifying spec.startingCSV with automatic approval? My concern is that users will set a startingCSV expecting that the specified version will persist on cluster and be surprised when it is updated.
| NAME READY UP-TO-DATE AVAILABLE AGE | ||
| my-operator 1/1 1 1 9m48s | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we highlight that a new installPlan for the next available version will be created when available? This will give users an idea how to perform a manual update.
| # How do I list Operators available to install? | ||
|
|
||
| There is an extension API in OLM named `PackageManifest` that contains information about existing `CatalogSources`, which is essentially a repository of CSVs, CRDs, and packages that define an operator in the cluster. By querying that API, you can see the list of available operators. | ||
| There is an extension API in OLM named `PackageManifest` that contains information about the content served by `CatalogSources`, which is essentially a repository of CSVs, CRDs, and packages that define a operator in the cluster. By querying that API, you can see the list of available operators. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a operator
This should be:
an operator
| If there are no `CatalogSource` objects present in the current namespace of the command above the list will contain all Operators found in global catalogs. To include Operators available to install from namespace catalogs simply supply it with the `kubectl` command: | ||
|
|
||
| ```bash | ||
| $ kubectl get packagemanifests | ||
|
|
||
| NAME CATALOG AGE | ||
| ... | ||
| my-operator My Catalog 31m | ||
| ... | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As someone that has worked with OLM before this is clear, but it may not be clear to users unfamiliar with OLM.
| NAME CATALOG AGE | ||
| ... | ||
| my-operator My Catalog 31m | ||
| ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You used [...] above to imply that additional output existed. Please chose a single format.
| Any operator tied to this `OperatorGroup` will now be confined to the permission(s) granted to the specified `ServiceAccount`. If the operator asks for permission(s) that are outside the scope of the `ServiceAccount` the install will fail with appropriate error(s). | ||
|
|
||
| An example of scoping an operator can be found [here]("https://operator-framework.github.io/olm-book/docs/how-do-i-scope-down-an-operator). | ||
| An example of scoping an operator can be found [here](./). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can probably remove this.
anik120
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR @dmesser. Had a few comments.
| You can then either interactively set the `spec.approved` property of the `InstallPlan` to `true` or _patch_ the object like so: | ||
|
|
||
| ```bash | ||
| kubectl patch installplan install-q4fmf -n olm --type merge -p '{"spec":{"approved":true}}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we get rid of the "What do I approve an update?" doc too if we're putting this information here?
|
|
||
| ## Install with automatic updates enabled | ||
|
|
||
| First, retrieve the package name, channel and catalog name and catalog source namespace from the `packagemanifest` of the desired Operator to install. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: package name, channel, CatalogSource name, and CatalogSource namespace from the packagemanifest...
| would return all CSVs across all namespaces and provide a high-level view of all custom installed operators. | ||
|
|
||
| If the ClusterServiceVersion fails to show up or does not reach the `Succeeded` phase, please check the [troubleshooting documentation](https://) to debug your installation. | ||
| If the ClusterServiceVersion fails to show up or does not reach the `Succeeded` phase, please check the [troubleshooting documentation](troubleshooting.md) to debug your installation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could link to (troubleshooting.md#clusterserviceversion-troubleshooting) to link to the more relevant section instead of the entire doc.
| NAME READY UP-TO-DATE AVAILABLE AGE | ||
| <name-of-your-operator> 1/1 1 1 9m48s | ||
|
|
||
| If the ClusterServiceVersion fails to show up or does not reach the `Succeeded` phase, please check the [troubleshooting documentation](troubleshooting.md) to debug your installation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as above about the (troubleshooting.md#clusterserviceversion-troubleshooting).
| $ kubectl describe packagemanifest my-operator | ||
| ``` | ||
|
|
||
| With this information a `Subscription` object can be created. This represents the intent to install an Operator from a particular catalog and keep it updated throughout the life cycle of the Operator via newly released version that got subsequently added to the referenced catalog. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe even
With this information, a
Subscriptionto an operator can be created.
instead of
With this information a
Subscriptionobject can be created.
And in @awgreene 's suggestion:
A subscription represents the desire to install an Operator from a particular catalog and keep it updated as new versions are subsequently added to the referenced catalog.
if we tweak it to
A subscription represents the desire to install an Operator from a particular catalog, and subscribe to updated version of the operators as they are subsequently added to the catalog.
then if could read like more of a user facing doc than dev facing doc.
| ``` | ||
| $ kubectl get csv -n <namespace-operator-was-installed-in> | ||
|
|
||
| The `Subscription` has successfully deployed the Operator when the `status.state` property reaches `AtLatestKnown`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this always true? If the CSV reaches a Failed state, will the Subscription not reach AtLatestKnow?
|
@dmesser: PR needs rebase. 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. |
Signed-off-by: dmesser dmesser@redhat.com