Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

ObjectMeta breaking change in 6.2.0

See original GitHub issue

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

Issue Analytics

State:
Created a year ago
Comments:17 (7 by maintainers)

Top GitHub Comments

1reaction

gyforacommented, Nov 2, 2022

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

1reaction

shawkinscommented, Nov 2, 2022

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.