rainest
commented
2 years ago @cmwylie19 this was necessary to handle the requirement listed at https://redhat-connect.gitbook.io/certified-operator-guide/troubleshooting-and-resources/offline-enabled-operators#override-the-image-variable, and the image is being set from https://github.com/Kong/kong-operator/blob/daf53502f16a2531349b97a92ee5ce0b94cf7f9f/watches.yaml#L7-L9
Per Red Hat, the implementation of that overrideValues feature requires a single value for both the image URL and tag. This is not a Helm requirement, and we'd originally written our values.yaml to use separate values.
Switching to a single value outright would have been a risky breaking change to our chart configuration, as existing users image.repository and image.tag would no longer be honored, forcibly upgrading their image versions if they did not see that they needed to change the key. We thus opted not to do this and added unifiedRepoTag as an alternative key that would override repository and tag.
While unifiedRepoTag isn't normally mentioned in documentation, my understanding is that this is fine, because these are then instead set from the operator Deployment's environment: https://github.com/Kong/kong-operator/blob/daf53502f16a2531349b97a92ee5ce0b94cf7f9f/olm/0.10.0/kong.v0.10.0.clusterserviceversion.yaml#L163-L168
Is that not the expected workflow in this case? I also find separating the images out of values.yaml confusing from a UX standpoint, but that is what the Red Hat docs indicate we should do.
Aside from that, do you have recommendations for effectively managing both community/operatorhub.io and Red Hat Marketplace variants of an operator? Marketplace variants require changes to core operator files rather than using supplementary configuration, which has been a barrier to us updating the Marketplace version consistently: there doesn't appear to be an obvious way to manage both without maintaining separate git repos or branches and dealing with merge conflicts, whereas we'd ideally like to maintain a single branch, tag once per version, and have build-time configuration handle the necessary differences between the two.
mpaulgreen
cmwylie19
Reported by Casey Wylie from Red Hat:
When the helm chart is installed from the Operator, extra values are added to the helm chart (unifiedRepoTag), which ultimately leads to the rendered manifests not having the correct image values.
To find out the exact values to use in the operator, I first installed the Kong Gateway (CP) through the helm chart exactly as described in the doc to ensure that I am able to reach the Kong Manager.
After successfully installing through the helm chart and verifying that I am able to reach the Kong Manager, I double checked the values being used in the install.
helm get values -n kong kongAfter doing a helm uninstall, ensuring that all pods, and pvc's are cleaned up, I install Kong through the operator using the same values.
From here, we can do a helm get values kong -n kong to see which values were used when the Operator deployed the helm chart and we see the problem.
The unifiedRepoTag is overlayed over the images, forcing the images to be pulled from the OpenShift registry. (As expected from the operator)
To look at the images from the kong deployment (RH Registry images):
k get deploy -n kong kong-kong -oyaml | grep image:The problem is not that it is pulling from the Red Hat repo, but that the images do not seem to be correct. We can verify this by checking the Kong version (We specified 2.8.0.0-alpine in the helm chart and the kong operator).
bash-3.2$ http $(k get routes -n kong kong-kong-admin -ojsonpath='{.status.ingress[0].host}') | jq -r .versionNow, to double check by uninstalling the operator and installing the helm chart again:
bash-3.2$ http $(k get routes -n kong kong-kong-admin -ojsonpath='{.status.ingress[0].host}') | jq -r .version: