Workaround obsolete API versions#7627
Workaround obsolete API versions#7627pho-enix wants to merge 1 commit intohelm:masterfrom pho-enix:k8sAPIVersionMitigation2
Conversation
This is a workaround for changes in API versions like extensions/v1beta1 => apps/v1 Ignore group and version. Signed-off-by: Sebastian Poehn <sebastian.poehn@gmail.com>
|
Drawback of this solution is that it will not catch resource conflicts of pre-existing resources with the same Kind but different GroupVersion. This can only happen for CRDs. I would expect that this case is rather rare. Impact might be that applying the change could fail. |
|
Can you explain the difference between this PR, #7575, and the one @jlegrone proposed in #7625? It's getting really unclear what is the goal with three PRs trying to tackle the same problem, and what the goals of each PR accomplishes. There's not a whole lot of information here to describe what's the intention behind these PRs. |
|
Sorry for raising confusion. I wanted to provide different implementation options so we can decide for the best one. #7627 Ignores kind: Deployment
apiVersion: apps/v1
metadata:
name: newkind: Deployment
apiVersion: naughty.inc/v1
metadata:
name: existingIn the Kubernetes maintained resource types there is no such conflicts. But CRDs could do weird things. Thus this implementation would not detect a pre-existing resource that does not belong to the Helm Release, for the case of clashing Kind + Name + Namespace. I would favour this solution as it is simple and the described corner-case sounds rather exotic to me.#7575 Same as #7627 but it partially handles the described corner-case. It will detect the clash, if the pre-existing or the created resource is a CRD. |
| func objectKey(r *resource.Info) string { | ||
| gvk := r.Object.GetObjectKind().GroupVersionKind() | ||
| return fmt.Sprintf("%s/%s/%s/%s", gvk.GroupVersion().String(), gvk.Kind, r.Namespace, r.Name) | ||
| return fmt.Sprintf("%s/%s/%s", gvk.Kind, r.Namespace, r.Name) |
There was a problem hiding this comment.
I considered this as well. Unfortunately ignoring group and version would allow collisions with custom resources from different API groups. Perhaps this is something we might be able to tolerate and call out in docs, but I'm not sure.
@bacongobbler @hickeyma any thoughts?
There was a problem hiding this comment.
If we could exclude gvk.GroupVersion().String() for native k8s resource types but not for custom resources, then I think this might be fine.
There was a problem hiding this comment.
This would be a change in Helm's existing behaviour, right? I don't think we can remove this behaviour if we made the assumption that we would not allow collisions in previous versions of Helm 3.
There was a problem hiding this comment.
We also do not have any assurance from Upstream Kubernetes that they won't at some point decide to have multiple kinds with the same names that have different group/version.
|
closed in favour of #7649. |
This is a workaround for changes in API versions like
extensions/v1beta1 => apps/v1
Ignore group and version.
Signed-off-by: Sebastian Poehn sebastian.poehn@gmail.com