documentation for new OLM command workflows#16
documentation for new OLM command workflows#16estroz merged 3 commits intooperator-framework:masterfrom
Conversation
|
@jmrodri @estroz @joelanford @dmesser - I have moved the PR (operator-framework/operator-sdk#2834) from Operator SDK to this repo. Please provide your inputs. |
276a96b to
30757cf
Compare
|
Updated the PR with man page for commands. |
|
/lgtm |
|
/approve |
joelanford
left a comment
There was a problem hiding this comment.
Looks great! Just want to clarify a few details.
30757cf to
b868155
Compare
|
Updated the doc based on reviews. |
This PR provides documentation explaining the workflows for proposed OLM commands with Operator SDK and a README describing the deployment of operator by following the suggested workflows.
b868155 to
e555f67
Compare
|
|
||
| OLM Workflow: | ||
|
|
||
| 1. Use `operator-sdk generate bundle` to generate kustomize base templates with CSV metadata and Dockerfile to build the operator. |
There was a problem hiding this comment.
@varshaprasad96 @dmesser a few thoughts on the base project -> OLM-ready workflow:
Eventually we'll want to move bundle (manifest) generation to kustomize to align with kubebuilder-style deployment. This will be especially relevant when CSV-less bundles come around. Therefore I don't thing we should write generate bundle so that it both ingests manifests from disk/stdin AND generates UI metadata. There should be a step, perhaps in operator-sdk init, that scaffolds UI metadata in a base. The user then updates it manually or via an interactive prompt, after which they can run kustomize build config/olm-catalog to generate their bundle to disk or as input to bundle create or run --olm.
The workflow then becomes:
$ operator-sdk init
Interactive metadata prompt. Please fill in the following UI fields:
...
$ operator-sdk create api --group cache --version v1 --kind Memcached
...Then:
$ make manifests-olm
kustomize build config/olm-catalog > config/olm-catalog/manifests/memcached-operator.bundle.yamlor
$ make bundle IMG=quay.io/example/memcached-operator:v0.0.1
kustomize build config/olm-catalog | operator-sdk create bundle quay.io/example/memcached-operator:v0.0.1or
$ make run-olm
kustomize build config/olm-catalog | operator-sdk run --olmThe make recipes above are just suggestions to illustrate how moving to kustomize will be much more flexible. I have something a little different set up in operator-framework/operator-sdk#2860 because we still need to regenerate CSV definitions from API types. Still tinkering around with that PR. Thoughts?
There was a problem hiding this comment.
Regardless on-disk manifests in a kubebuilder project are mostly just bases, so some part of bundle generation needs to be run through kustomize. We have two options then, which are inverses:
- Run
kustomize | operator-sdk, which is how kubebuilder does things. - Invoke
kustomizewithinoperator-sdk.
The former is a lot more appealing to me.
|
This PR has been updated to a full EP. |
|
@estroz: GitHub didn't allow me to request PR reviews from the following users: varshaprasad96. Note that only operator-framework members and repo collaborators can review this PR, and authors cannot review their own PRs. DetailsIn response to this:
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. |
c5906d5 to
839dc5c
Compare
|
@camilamacedo86 @shawn-hurley @joelanford @hasbro17 I removed the |
|
is the convention normally "operator-sdk or the other way ? that might be made clearer or more consistent if possible. |
|
@jmccormick2001 when talking about the binary, I try to use |
| ```console | ||
| $ make manifests | ||
| controller-gen "crd:trivialVersions=true" rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/bases | ||
| $ kustomize build config/packages | operator-sdk generate packagemanifests -q --channel beta --version 0.0.1 |
There was a problem hiding this comment.
Should we run $ kustomize build config/packages | operator-sdk generate packagemanifests -q --channel beta --version 0.0.1 ? Could we not be a new target make bundle-manifestfor example?
There was a problem hiding this comment.
We're going to transition away from package manifests at some point, although we don't have a concrete timeline. Regardless I don't think it's a good idea to add this target by default. There will be docs explaining how to add this to the Makefile at the very least.
camilamacedo86
left a comment
There was a problem hiding this comment.
Just few nits now.
After addressing them it would be for me:
/lgtm
/approve
|
New changes are detected. LGTM label has been removed. |
jmrodri
left a comment
There was a problem hiding this comment.
A few nits regarding the title and template usage. Also, I wanted clarification on the open question. All in all really good.
old Operator SDK project layouts
This PR provides documentation explaining the workflows for
proposed OLM commands with Operator SDK and a README describing
the deployment of operator by following the suggested workflows.