search

operator-framework / kubectl-operator

Manage Kubernetes Operators from the command line
https://operatorframework.io/
Apache License 2.0
128 stars 37 forks source link

OLMv1 Operator install/uninstall #85

Closed tmshort closed 1 year ago

tmshort commented 1 year ago

Fixes #83

Implements Jira OLM-2863 and OLM-2869

Signed-off-by: Todd Short tshort@redhat.com

tmshort commented 1 year ago

Based on #84

tmshort commented 1 year ago

Also interested in a convo weighing pros/cons of separate subcommand vs different CLI based on envvar.

Part of my envvar motivation was that we would eventually flip the default to the OLMv1 CLI, in which case no one using it already would need to change their invocations.

Con of that, I suppose, is discoverability, which I was banking on relying on docs for.

Which is why I was originally thinking of an --api-version option instead for install/uniinstall; but that gets complicated by all the OLMv0 options.

Alternatively, we could move OLMv0 to a branch, and move everything to OLMv1. Since that's the direction we're headed.

joelanford commented 1 year ago

but that gets complicated by all the OLMv0 options.

Yeah exactly. I think we definitely want a separate CLI one way or the other.

Alternatively, we could move OLMv0 to a branch, and move everything to OLMv1.

We could but I don't think we should do that until OLMv1 GA. There are upstream projects using this with OLMv0 that we would break. (e.g.: https://cert-manager.io/docs/installation/operator-lifecycle-manager/#option-3-manual-install-via-kubectl-operator-plugin)

I think our approaches both do the correct things:

  1. Leave the default OLMv1 experience untouched.
  2. Ensure we can keep shipping improvements and fixes for OLMv0.
  3. Add OLMv1 support such that it is available in releases for those that want to begin experimenting with pre-GA OLMv1.

I suppose we could make a v1 branch for v1.y.z[-pre] tags and essentially maintain main for the time being as the v0 branch. That seems overly complicated to me though. And most importantly, it doesn't play well with the krew index which contains a pointer to a single version of the plugin.

IMO putting the OLMv1 stuff in the main branch is a good avenue for letting people know about OLMv1 progress, and maybe getting feedback.

tmshort commented 1 year ago

ping @awgreene for review?

tmshort commented 1 year ago

@joelanford @dtfranz is this good?

perdasilva commented 1 year ago

very nice! thank you!!

perdasilva commented 1 year ago

/approve

openshift-ci[bot] commented 1 year ago

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: perdasilva, tmshort Once this PR has been reviewed and has the lgtm label, please assign joelanford for approval by writing /assign @joelanford in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/operator-framework/kubectl-operator/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
perdasilva commented 1 year ago

looks good to me too ^^ sorry I couldn't approve

tmshort commented 1 year ago

looks good to me too ^^ sorry I couldn't approve

Thanks. @awgreen can likely merge, or @joelanford. The [Squash and merge] button is live for me... 🤔

joelanford commented 1 year ago

We never directly talked about the envvar enablement mode like in my PR vs the separate subcommand in this one. I'm somewhat partial to the envvar approach but I'm also not going to stand in the way of progress if the consensus is the separate subcommand approach.

tmshort commented 1 year ago

The ticket OLM-2869 had it as a an extra keyword as done in this PR.