Better local deployment workflow

[fanminshi]

Currently, the the deployment workflow of an operator is:

• Build the image: operator-sdk build $Image
• Push the image to a public registry: docker push $Image
• Create the operator deployment: kubectl create -f deploy/operator.yaml
• Then test out the operator image via kubectl

Development cycle can be faster if we can avoid building/pushing the image. A workflow like the following maybe better (idea learned from kubebuilder):

• Build the operator binary bin/operator that knows kubeconfig so that the client can access the kubernetes cluster that's associated with kubeconfig.
• Execute ./bin/operator
• Then test out the operator via kubectl

The proposed approach saves developer time from building and pushing Image to a registry and operator deployment.

Action Items:

• Implement operator-sdk up command ref: operator-sdk/cmd: add up command #219
• Document how to use the operator-sdk up ref: doc: modify user_guide with watched namespace fixed #279

[fanminshi]

cc/ @philips If you can take a look of this, it will be great. I think you have proposed this idea earlier as well.

[philips]

Yes! I think the model outlined in kubebuilder is similar and it is certainly faster! :)

[fanminshi]

I am proposing to have a operator-sdk up or something better named to help user to achieve the better local workflow.

Instead of the users follow the operator-sdk build $Image and docker push $Image model every time they need to test out their code locally, the users can just call operator-sdk up --kubeconfig=<your-kubeconfig-path> to run the operator locally.

The operator-sdk up compiles and runs the operator binary and gives it's internal Kubernete client the access to a kubernetes cluster by setting the client config to that of the passed in --kubeconfig.
In this way, you can think that your local machine is a "pod" of a Kubernete cluster, and it can watch, query, and mutate anything in that Kubernete cluster.

[spahl]

That is quite useful indeed.

There are two ways of bringing something up for dev and test. One local (for rapid iteration) one where the operator gets builts, pushed to the registry and started in the remote cluster (for ci testing for example or developing on the actual container image and testing that).

IMHO It would be good for the "up" command to allow both. Something like "up" for remote and "up --local" for the local dev workflow.

[fanminshi]

IMHO It would be good for the "up" command to allow both. Something like "up" for remote and "up --local" for the local dev workflow.

I am thinking about having separate sub commands for local and cluster deployment.
like up local [args] [flags] and up cluster [args] [flags] or r/up/deploy/ for better naming.

The reason for having separate command is that I suspect that up cluster might have a total of different flags and args than that of up local. If we combine the up cluster and the up local into one command, I suspect most of the flags won't be apply to both and also may cause confusion to users.

[spahl]

Yeah you are right the subcommands are good and more explicit than flags.

[Verolop]

I agree with having separate commands, since the definitions and use cases don't necessarily overlap

[fanminshi]

operator-sdk up local command is implemented via #219

I'll add doc to describe how to use it on the next few days.