This post will share some tips in developing changes for the submariner gateway, and testing those in a live environment. While the development environment can create kind based clusters in your laptop, it’s sometimes necessary to test the integration with specific clouds as you develop.
Please bear in mind that some of the details are specific to the development branch during the 0.9 cycle of submariner, but the imageOverride technique will be valid.
I normally use a couple of scripts, one for building and pushing my images, another one for deploying the images.
This is the builder:
#!/bin/bash
set -e
rm package/.image.submariner bin/linux/amd64/submariner-engine || true
make bin/linux/amd64/submariner-engine package/.image.submariner
docker tag quay.io/submariner/submariner:devel quay.io/mangelajo/submariner:devel
docker push quay.io/mangelajo/submariner:devel
And this is the deployer:
#!/bin/sh
set -e
kubectl patch Submariner submariner -n submariner-operator -p '{"spec": {"ceIPSecDebug": true, "version":"devel", "imageOverrides": {"submariner": "quay.io/mangelajo/submariner:devel" }}}' --type=merge
kubectl delete pod -n submariner-operator -l app=submariner-engine
This deployer modifies the submariner definition handled by the submariner-operator, and overrides the submariner (gateway) image to quay.io/mangelajo/submariner:devel which is the image I build I push on the previous script.
Then it kills the existing pods for the submariner gateway, which will force the reload.
Please note that I’m using the “devel” version, which will make the operator enable the ImagePullPolicy as Always, re-checking the remote repo for new images and ignore the local cache everytime a pod is started.