Operator-sdk: Change imagePullPolicy to speed up the development lifecycle

[matyix]

The operator-sdk build regenerates operator.yaml with imagePullPolicy: Always
During development phase of an operator the imagePullPolicy: Always requires developers to push the image to a Docker repo before being able to test the changes.

This extra step could be avoided if the operator-sdk build generated operator.yaml with imagePullPolicy: IfNotPresent as in that case the image that is already on the developer's machine will be used.

[fanminshi]

@matyix I am using minikube to do local testing. I notice that if I just build and don't push the newest operator image to a docker repo and have imagePullPolicy: IfNotPresent, the minikube cluster won't pick up the newest image when deploying the operator because it uses a previous image that's cached locally. That's why we had the imagePullPolicy: Always.

If you haven't seen this issue https://github.com/coreos/operator-sdk/issues/142, we are working on improving the local development/testing flow.

[matyix]

thx @fanminshi - I see, thanks for #142, I was not aware of that. We use Docker Edge (with K8s support) for local testing and with that, it works fine as it uses the same/common docker daemon. I believe this should work with Minikube as well in your case - Minukube does cache the images, however, you can delete the cache - though I have not tested, just out of curiosity please let me know if that is the case.

[fanminshi]

@matyix interesting about the cache thing from minikube. I'll take a look into it. It also seems to me that we can use the docker daemon that's within the minikube for building the operator image. https://github.com/kubernetes/minikube/blob/master/docs/reusing_the_docker_daemon.md. In that way, we don't have to push the image to the registry.

[ghost]

I've not experience the caching problem with IfNotPresent policy. I do use the minikube's docker daemon, e.g. eval $(minikube docker-env), to store local built cached images.

[fanminshi]

@matyix We have added operator-sdk up local command to speed up local development process:

$ operator-sdk up local -h
The operator-sdk up local command launches the operator on the local machine
by building the operator binary with the ability to access a
kubernetes cluster using a kubeconfig file.

Usage:
  operator-sdk up local [flags]

Flags:
  -h, --help                    help for local
      --kubeconfig string       The file path to kubernetes configuration file; defaults to $HOME/.kube/config
      --namespace string        The namespace where the operator watches for changes. (default "default")
      --operator-flags string   The flags that the operator needs. Example: "--flag1 value1 --flag2=value2"

See usage for more detail.

I don't think we no longer need to modify imagePullPolicy: Always to speed up the development process. The imagePullPolicy: Always in the operator.yaml is important for production usage because we want the Kubernetes to always pull for the latest image.

[matyix]

Awesome, thanks @fanminshi. I agree and close the issue now. Thanks for the resolution.