Is it safe to only update the api version, if the content is different for the new version
marckhouzam opened this issue · 3 comments
When moving from one api version to another, we sometimes need to change the content of the yaml definition of the object.
Is it safe from helm's perspective for the mapkubeapis plugin to only change the version and not the content?
This was mostly answered in #34 but in a helm dev call there was a mention that the three-way merge could be something to think about with respect to this issue.
For example, in kube 1.22, the Ingress resource versions extensions/v1beta1 and networking.k8s.io/v1beta1 are removed and we must migrate to networking.k8s.io/v1. However, when migrating to the new version, some fields must be changed and some added (https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122).
Is it safe for the mapkubeapis plugin to ignore those field changes? Could helm's three-way merge logic be affected by a helm manifest that differs from the actual yaml stored in kubernetes?
If there could be issues, we may want to look at using the kubectl convert plugin to apply all changes to the helm manifest.
In fact, using the plugin may be interesting regardless as it has the potential to handle every format properly.
@hickeyma I'm hoping you may have an opinion about this.
@marckhouzam Thank you for raising this.
Some background. The plugin was designed to just update the apiVersion to the supported version. At the time, there seemed no issue with backwards compatibility of object fields. This was around the time of the Kubernetes 1.16 release when API versions started to be removed.
For example, in kube 1.22, the Ingress resource versions extensions/v1beta1 and networking.k8s.io/v1beta1 are removed and we must migrate to networking.k8s.io/v1. However, when migrating to the new version, some fields must be changed and some added (https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122).
Is it safe for the mapkubeapis plugin to ignore those field changes? Could helm's three-way merge logic be affected by a helm manifest that differs from the actual yaml stored in kubernetes?
This is something that would need to be verified if it is an issue or not.
If there could be issues, we may want to look at using the kubectl convert plugin to apply all changes to the helm manifest.
In fact, using the plugin may be interesting regardless as it has the potential to handle every format properly.
I had not known about this tool, thanks for the insight. This might be worth investigating as an alternative to how the plugin updates the release manifest.
@marckhouzam Is this something that you would like to investigate further?
For example, in kube 1.22, the Ingress resource versions extensions/v1beta1 and networking.k8s.io/v1beta1 are removed and we must migrate to networking.k8s.io/v1. However, when migrating to the new version, some fields must be changed and some added (https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122).
Is it safe for the mapkubeapis plugin to ignore those field changes? Could helm's three-way merge logic be affected by a helm manifest that differs from the actual yaml stored in kubernetes?This is something that would need to be verified if it is an issue or not.
I wonder if @mattfarina would have an opinion on this?
If there could be issues, we may want to look at using the kubectl convert plugin to apply all changes to the helm manifest.
In fact, using the plugin may be interesting regardless as it has the potential to handle every format properly.I had not known about this tool, thanks for the insight. This might be worth investigating as an alternative to how the plugin updates the release manifest.
@marckhouzam Is this something that you would like to investigate further?
I will try to allocate some time to try out using kubectl-convert and report back what I find.
I can confirm that the mentioned scernario is true
Old helm deployments done with Ingress extensions/v1beta1 when attempting to upgrade them on k8 1.22 , it. fail as the apiversion is not recognized, using mapkubeapis corrects the apiversion to the supported networking.k8s.io/v1, however the helm upgrade still fails as the new api version has different format, so for instance the lack of pathType also causes the validation to fail, likewise name and port format is different in that version.
Only workaround found was using the manual method described on the documentation for decoding the configmap , update the ingress section using the output of kubectl-convert encode it back, and then helm upgrade deploys smoothly.
So I agree there would be scenarios where kube-convert transformation of the manifest would be helpful.