-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better local deployment workflow #142
Comments
cc/ @philips If you can take a look of this, it will be great. I think you have proposed this idea earlier as well. |
Yes! I think the model outlined in kubebuilder is similar and it is certainly faster! :) |
I am proposing to have a Instead of the users follow the The |
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. |
I am thinking about having separate sub commands for local and cluster deployment. The reason for having separate command is that I suspect that |
Yeah you are right the subcommands are good and more explicit than flags. |
I agree with having separate commands, since the definitions and use cases don't necessarily overlap |
I'll add doc to describe how to use it on the next few days. |
Hi, what's the latest recommended approach to this? I see Note that the non-local flow of pushing and pulling from DockerHub works with |
Currently, the the deployment workflow of an operator is:
operator-sdk build $Image
docker push $Image
kubectl create -f deploy/operator.yaml
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):
bin/operator
that knows kubeconfig so that the client can access the kubernetes cluster that's associated with kubeconfig../bin/operator
kubectl
The proposed approach saves developer time from building and pushing Image to a registry and operator deployment.
Action Items:
operator-sdk up
command ref: operator-sdk/cmd: add up command #219operator-sdk up
ref: doc: modify user_guide with watched namespace fixed #279The text was updated successfully, but these errors were encountered: