What happened (please include outputs or screenshots):
Commit 5ef5796 ("auto generated by openapi generator v6.6.0", merged 2026-03-28) renamed several V1ServiceSpec fields as a side effect of the openapi-generator upgrade:
external_i_ps → external_ips
cluster_i_ps → cluster_ips
Any code accessing .external_i_ps or .cluster_i_ps on a V1ServiceSpec object will raise AttributeError after upgrading to a client built from this commit (v35.x).
What you expected to happen:
These renames should be documented in the breaking changes section for the openapi-generator v6.6.0 upgrade alongside the other four breaking changes that were listed:
# Breaking Change from upgrading openapi generator to v6.6.0
- Legacy dict(str, str) syntax is no longer supported in ApiClient deserializer. Only modern dict[str, str] syntax is supported.
- All models __init__ will now use Configuration.get_default_copy() instead of Configuration() ...
- ApiClient's `update_params_for_auth` method has one parameter name changed from `querys` to `queries`.
- Configuration auth uses 'BearerToken' instead of 'authorization' in api_key.
How to reproduce it (as minimally and precisely as possible):
from kubernetes import client
spec = client.V1ServiceSpec()
spec.external_i_ps = ["1.2.3.4"] # AttributeError on v35.x+
Or when deserializing a Service object from the API — the externalIPs JSON field will populate external_ips instead of external_i_ps.
Anything else we need to know?:
The rename is caused by openapi-generator v6.6.0 producing more natural Python snake_case names — consecutive uppercase abbreviations like IP are no longer split into _i_p. This likely affects other models beyond V1ServiceSpec wherever field names contained IP, IPs, or similar abbreviations. A broader audit of renamed fields across all models may be warranted, and a migration note should be added to the changelog.
The prior behavior (using external_i_ps) was present through commit 82420b3 (December 2025).
Environment:
- Kubernetes version (
kubectl version): N/A (client-side only)
- OS (e.g., MacOS 10.13.6): N/A
- Python version (
python --version): N/A
- Python client version (
pip list | grep kubernetes): v35.x (commit 5ef5796 and later)
What happened (please include outputs or screenshots):
Commit
5ef5796("auto generated by openapi generator v6.6.0", merged 2026-03-28) renamed severalV1ServiceSpecfields as a side effect of the openapi-generator upgrade:external_i_ps→external_ipscluster_i_ps→cluster_ipsAny code accessing
.external_i_psor.cluster_i_pson aV1ServiceSpecobject will raiseAttributeErrorafter upgrading to a client built from this commit (v35.x).What you expected to happen:
These renames should be documented in the breaking changes section for the openapi-generator v6.6.0 upgrade alongside the other four breaking changes that were listed:
How to reproduce it (as minimally and precisely as possible):
Or when deserializing a Service object from the API — the
externalIPsJSON field will populateexternal_ipsinstead ofexternal_i_ps.Anything else we need to know?:
The rename is caused by openapi-generator v6.6.0 producing more natural Python snake_case names — consecutive uppercase abbreviations like
IPare no longer split into_i_p. This likely affects other models beyondV1ServiceSpecwherever field names containedIP,IPs, or similar abbreviations. A broader audit of renamed fields across all models may be warranted, and a migration note should be added to the changelog.The prior behavior (using
external_i_ps) was present through commit82420b3(December 2025).Environment:
kubectl version): N/A (client-side only)python --version): N/Apip list | grep kubernetes): v35.x (commit5ef5796and later)