V1EndpointPort renamed to CoreV1EndpointPort in 21.7.0

[dulek]

What happened (please include outputs or screenshots):
For some reason b8e0b3d renamed V1EndpointPort to CoreV1EndpointPort. I don't know the root cause but as other V1Endpoint* resources are not renamed, I guess it's some mistake.

What you expected to happen:
The type to stay with the same name.

How to reproduce it (as minimally and precisely as possible):
Just diff the code.

Anything else we need to know?:

Environment:
This is unrelated to the env.

[roycaihw]

It happened because a new model DiscoveryV1EndpointPort was introduced. When we generate the client from the openapi spec, we remove parts of the package name but will make sure there is no conflicting model names. CoreV1EndpointPort used to be the only V1EndpointPort, until DiscoveryV1EndpointPort was introduced. The same issue happens to the java client: https://github.com/kubernetes-client/java/pull/1936/files.

I think we should document this as a breaking change.

Ideally we could keep CoreV1EndpointPort as V1EndpointPort and name DiscoveryV1EndpointPort as DiscoveryV1EndpointPort. However it is non-trivial for the client generator to tell which API was the existing one and which API was newly added.

cc @yliaog

[dulek]

Alright, thanks for explanation. Keeping some alias name would probably be best, right now I'm forced to catch AttributeError and fallback to CoreV1EndpointPort [1] in our lib consuming the client. Unfortunately we're unable to just pin the client version as the code got to work with several OpenStack versions, meaning different sets of upper constraints.

[1] https://opendev.org/openstack/kuryr-tempest-plugin/commit/34378686c705359146dc81d116aabecf91a625a7

[roycaihw]

I agree keeping alias names will be nice. Some challenges:

1. Detect renames: for each removed model in kubernetes/client/models/__init__.py, we should check if a new model with a similar (longer or shorter) name was added-- this challenge also exists if we want to just document the breaking change.
2. Maintain multiple iterations: imagine we keep V1EndpointPort as an alias of CoreV1EndpointPort, and in a future release CoreV1EndpointPort gets deprecated and removed-- DiscoveryV1EndpointPort now becomes V1EndpointPort. By deisn we will remove the V1EndpointPort->CoreV1EndpointPort alias and add a DiscoveryV1EndpointPort->V1EndpointPort alias. However existing applications which used the V1EndpointPort->CoreV1EndpointPort alias may now accidentally use the discovery v1 model, which could also be a breaking change. IMO it's worse than an AttributeError because the application could continuously function but emit some unexpected behavior.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.