Install operator instance from in-cluster operator version resource

[zen-dog]

Summary: The current kudo install ... command accepts either a remote repo operator name, a URL, or a local folder/tgz. This PR allows the user to install an instance from an existing in-cluster operator version using the newly introduced --in-cluster option:

❯ ./bin/kubectl-kudo install first-operator --operator-version=0.2.0 --in-cluster
operatorversion default/first-operator-0.2.0 already installed
instance default/first-operator-instance created

This way kudoctl will only look for already installed operator versions (one can list them using kudoctl get operatorversions) and does not need access to the repo/package files.

Signed-off-by: Aleksey Dukhovniy alex.dukhovniy@googlemail.com

Fixes #1678

[zen-dog]

Note, that kudo upgrade and kudo package list cli commands could also use the --in-cluster option to address the in-cluster resources (instead of packages). However, current PR does not touch these commands.

[zen-dog]

but there are a number of other flags that don't make sense either like: --app-version, --operator-version, --repo

You're right about the --repo option (fixed). But the other two are absolutely used. See this long thread about the reasoning but essentially give a cluster with OperatorVersions:

zookeeper-0.2.0
zookeeper-0.3.0

and a command:

$ kudo install zookeeper --in-cluster

the InCluserResolver will apply the same rules as with the repo: pick the highest operatorVersion, operators without an appVersion are sorted at the back etc. You could also specify --operator-version and --app-version and they will be used during resolving. So, it actually resolves your operator, hence the name and the interface 😉

However, the original idea (set this commit) didn't need this logic and basically just fetched the right OV resource.

[alenkacz]

I don't have a strong opinion here so I'll let people with stronger opinions reconcile -> removing my rejection :)