Integrate kind into local deployment to no longer require minikube for development #1171
Conversation
|
This PR will not work until we move the images to a separate repo and have them pre built |
viniciusdc
added
the
status: in progress 🏗
|
@iameskild how is the work with the docker images? is this unblocked now? |
|
@viniciusdc the PR to transfer images has been submitted, reviewed and is awaiting final approval :) |
|
As the docker images are now transferred over, we can work on this again. I've prioritized integrating this as part of nebari-dev/nebari-docker-images#2. This will help split up the dependencies for a full integrated Kubernetes tests from a Jupyterlab/Jupyterhub one (anything that only requires a simple ecosystem built) |
viniciusdc
removed
the
status: blocked ⛔️
viniciusdc
force-pushed
the
fix-minikube
branch
from
bf82494
to
f9f6bf7
Compare
As the original docker build pipeline was moved to a separate repo, those changes need to be reflected in the workflow as well: - Update docker image labels and registry (hardcoded to main) - Remove docker build stage, added docker pull in place use bash loop for docker pull fix looping bash syntax
there is no kind config yet switch image tags to test kind load Run test Run test fix formating issue fix formating issue
viniciusdc
added
needs: review 👀
|
@costrouc could you have a look? I will change add the existing name change in a separate PR later. |
| minikube version | ||
| kubectl version | ||
| - name: Use minikube docker daemon | ||
| images=${{ env.image_names }} |
There was a problem hiding this comment.
I think this is double work. We should remove all the docker pull and kind load since kubernetes will pull as needed
|
Hi @costrouc, I added a new deployment mode to |
There was a problem hiding this comment.
@viniciusdc thanks for pushing this PR through the finish line. This looks good to me. My concern is that we will need to mention the breakage of local -> existing but we will do this in the docs and I do not believe that many groups are depending on this feature.
This PR aims to significantly simplify development of qhub for local deployment using kind. Kind will also allow us to test multinode setups locally.
This PR is a work in progress and to me uses the actual meaning of
provider: localimplying that a local kubernetes cluster will be spun up. I suggest we change the priorprovider: local->provider: existing.The load balancer is automatically configured in the
qhub deploystage02-infrastructure/localmeaning that the script/metallb ... is no longer required. Also make the only assumption for a local deployment that there is docker.