Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
120 changes: 120 additions & 0 deletions doc/proposals/olm-cmd-workflows.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,120 @@
---
title: README describing new command workflows for olm enabled operators
authors:
- "@varshaprasad96"
reviewers:
- "@jlanford"
- "@dmesser"
- "@estroz"
approvers:
- "@jlanford"
- "@dmesser"
- "@estroz"
creation-date: 2020-04-09
last-updated: 2020-04-09
status: provisional
---

# README describing new command workflows for olm enabled operators
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when referring to the product or project name I think we should use capitals. olm -> OLM


## Release Signoff Checklist

- \[ \] Enhancement is `provisional`
- \[ \] Design details are appropriately documented from clear requirements
- \[ \] Test plan is defined
- \[ \] Graduation criteria for dev preview, tech preview, GA
- \[ \] User-facing documentation is created.

## Summary

This proposal provides documentation describing the possible workflows of new commands for generating operator manifests with user inputs and publishing operator bundle image for OLM to deploy the operator.

We plan to improve the developer experience for operator authors using Operator SDK with OLM by:
1. Providing an interactive subcommand to get inputs for generating CSV.
2. Providing a single command for generating operator manifests and for creating operator bundle image.

## Motivation

Currently, the `operator-sdk generate csv` command is used for generating CSVs, which sacffolds the project and writes the csv manifest on disk. This process still requires the developers to manually edit the CSV when any of the required fields are missing. Also, with the depreciation in the use of package manifests for olm, generating CSVs and creating operator bundle image does not require two separate commands. Integrating both the functionalities and providing a single command with an interactive input for collecting the required UI metadata to generate CSV as well as for building an operator bundle image will result in a better developer experience.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: sacffolds -> scaffolds
typo: csv manifest -> CSV manifest
did you mean deprecation? instead of "depreciation"?
typo: for olm -> for OLM


## Goals

The proposal is aimed at expalining the resulting process of developing an olm enabled operator from scratch with the above mentioned improvements.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: expalining -> explaining
typo: olm -> OLM


## Proposal

### README
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is README the correct the subheading?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure completely. But this is a fake README to give an overview about the process.


The following document discusses workflows for creating a new operator and running it with OLM:

Operator creation workflow:

1. Create a new operator project using the SDK Command Line Interface(CLI)
2. Define new resource APIs by adding Custom Resource Definitions(CRD)
3. Define Controllers to watch and reconcile resources
4. Write the reconciling logic for your Controller using the SDK and controller-runtime APIs
5. Use the SDK CLI to build and generate the operator deployment manifests

OLM Workflow:

1. Use `operator-sdk generate bundle` to generate kustomize base templates with CSV metadata, build and push the operator bundle image to the specified registry.
* If the kustomize template having the operator and UI metadata is present, it is utilized along with the existing CRDs to build the operator image bundle.
* If the kustomize template is not present, provide inputs regarding the UI metadata to the interactive prompts appearing further.
2. Use `operator-sdk run --olm` to generate kustomize base template with operator metadata, build and run the operator.

### Create and deploy an app-operator

```sh
# Create an app-operator project that defines the App CR.
$ mkdir -p $HOME/projects/example-inc/
# Create a new app-operator project
$ cd $HOME/projects/example-inc/
$ operator-sdk new app-operator --repo github.com/example-inc/app-operator
$ cd app-operator

# Add a new API for the custom resource AppService
$ operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=AppService

# Add a new controller that watches for AppService
$ operator-sdk add controller --api-version=app.example.com/v1alpha1 --kind=AppService

# Set the username variable
$ export USERNAME=<username>

# Build and push the app-operator image to a public registry such as quay.io
$ operator-sdk build quay.io/$USERNAME/app-operator

# Login to public registry such as quay.io
$ docker login quay.io

# Push image
$ docker push quay.io/$USERNAME/app-operator

# Generate kustomize base templates with UI metadata and publish operator in a bundle image
# If you would like to write the operator manifests on disk, specify the path using the flag "--output-dir"
$ operator-sdk generate bundle <IMAGE_REGISTRY>/<TAG>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple thoughts to make this command even shorter:

--package - could we derive this from the operator (project) name by default?
--kustomize-dir - it's already proposed as optional given we have a default, that's great
--output-dir - it's already optional, so we are good

Given the above, the command would be shortened to: operator-sdk generate bundle <image>:<tag> which looks really appealing in a (repetitive) workflow.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, as the package name can be derived from the operator project, have made it optional if the user wants a different package name than the project name.

--package <Name of the package that bundle image belongs to>
--kustomize-dir <Path to the directory containing kustomize base templates [default:./config/]>
--output-dir <Optional output directory if operator manifests are to be written on disk>

# If the kustomize templates do not contain UI metadata for populating CSV, provide inputs for the interactive prompts that would appear further
$ Provide DisplayName for your operator:
$ Provide version for your operator:
$ Provide minKubeVersion for CSV:
Comment on lines +101 to +103
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these are new prompts we are asking the user, are we thinking about internationalizing the strings? We should at least call out what our plan is for i18n.

https://github.com/leonelquinteros/gotext

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will there be input validation? If so, how do we ask the user to re-enter?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are the UI metadata fields which could asked along with the command. An exhaustive list is here: https://docs.google.com/document/d/1dP6Y9DlE3TuoVXaOdYbuKjo97Qxwqy-07A7msf6_cTQ/edit
We haven't discussed about the implementation yet. Should it be included in the doc?

...

# Deploy and test the operator on the cluster using OLM
# If path to the kustomize base templates is not present, they are generated from scratch inside ./config folder
$ operator-sdk run --olm --kustomize-dir <Path to directory containing kustomize base templates>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to my previous comment, I am looking for ways to make this even shorter.

--kustomize-dir - can we use the same default like we do in generate bundle?
--operator-version - can we use the the version string from CSV as a default?

If both is possible, this command would be a mere operator-sdk run --olm which is really nice.

Copy link
Copy Markdown
Member Author

@varshaprasad96 varshaprasad96 Apr 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have modified the operator-sdk run --olm command to:

  1. Deploy the operator for the version specified in the kustomize template for generating CSV.
  2. Use the specified --version if present.

--operator-version <Version of the operator>
INFO[0000] loading packages
INFO[0000] generating manifests
...
NAME NAMESPACE KIND STATUS
appservice.app.example.com default CustomResourceDefinition Installed
app-operator.<version> default ClusterServiceVersion Installed
...

# Cleanup
$ operator-sdk cleanup --olm --operator-version <Version of the operator>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could make --operator-version optional by either taking the version string from the CSV or clean up the first operator we find by this name.

```