kubernetes-client: ObjectMeta breaking change in 6.2.0

Describe the bug

In https://github.com/fabric8io/kubernetes-client/commit/711482cf7b75081693883d1fc538e65dd8f8043b there was a breaking change to the ObjectMeta object.

The clusterName field was removed.

This also makes CRD-s generated using the generator that contain any ObjectMetadata field to be non backward compatible.

Fabric8 Kubernetes Client version

6.2.0

Steps to reproduce

Check code / generated CRD

Expected behavior

backward compatibility for objectmeta

Runtime

Kubernetes (vanilla)

Kubernetes API Server version

1.25.3@latest

Environment

macOS

Fabric8 Kubernetes Client Logs

No response

Additional context

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 17 (7 by maintainers)

Most upvoted comments

Thank you! It is indeed not a breaking change in practice it seems.

I’m not really sure how we should fix this one. My best guess is that the CR deserializer should be tweaked to ignore this field.

It already does - since it’s ultimately using io.fabric8.kubernetes.api.model.ObjectMeta correct?

I’m not sure how this change could be breaking - or at least it shouldn’t be under normal circumstances. If you are using explicitly setting the clusterName field for create / update - which the docs tell you will be ignored - then with this updated api that direction option will be removed.

You could set the clusterName via additionalProperties, again documented as ignored / dropped by the api server. Only if you have enabled some kind of field validation, which we won’t generally support until #4136 could you see a problem.