Remove TPR resource in favor of CRD #48152
Comments
k8s-ci-robot
added
the
sig/api-machinery
|
Seems appropriate for alpha transition
…On Tue, Jun 27, 2017 at 4:39 PM, David Eads ***@***.***> wrote:
In 1.6 TPR was indicated as unstable and subject to change (
https://github.com/kubernetes/kubernetes.github.io/blob/release-1.6/docs/
tasks/access-kubernetes-api/extend-api-third-party-resource.md), near the
end of 1.6 we talked about a new API and how we would transition (
https://github.com/kubernetes/community/blob/master/sig-api-machinery/api-
extensions-position-statement.md#q-should-tpr-maintain-
compatibility-or-should-we-break-compatibility-to-fix-and-extend-it), in
1.7 we updated the docs to announce deprecation and provided the
alternative and a clean semi-automatic migration path (https://github.com/
kubernetes/kubernetes.github.io/blob/release-1.7/docs/
tasks/access-kubernetes-api/extend-api-third-party-resource.md), they
were specifically called out in the release notes (kubernetes/enhancements#306
<kubernetes/enhancements#306>), there is
acknowledgement in the community that they will be removed (
https://coreos.com/blog/custom-resource-kubernetes-v17), and following
our deprecation policy (https://kubernetes.io/docs/
reference/deprecation-policy/) we can remove them in 1.8 and focus our
efforts on adding features like validation to CRDs (
kubernetes/community#708
<kubernetes/community#708>).
@kubernetes/sig-api-machinery-misc
<https://github.com/orgs/kubernetes/teams/sig-api-machinery-misc> @enisoc
<https://github.com/enisoc> @smarterclayton
<https://github.com/smarterclayton> @sttts <https://github.com/sttts>
@nikhita <https://github.com/nikhita>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48152>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ABG_p-QByBKQJy9eD7vEuBd7OTqUHIyXks5sIWh2gaJpZM4OHKOv>
.
|
|
The migration helper intentionally leaves behind the etcd data for TPRs, for rollback and to prevent watchers from seeing deletes. Should we clean up this data eventually? Is there a precedent for how we handle etcd data for resources that were deprecated and removed? |
|
No precedent today.
…On Tue, Jun 27, 2017 at 5:19 PM, Anthony Yeh ***@***.***> wrote:
The migration helper <#46677>
intentionally leaves behind the etcd data for TPRs, for rollback and to
prevent watchers from seeing deletes.
Should we clean up this data eventually? Is there a precedent for how we
handle etcd data for resources that were deprecated and removed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48152 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_p6xilaoLVK7r7vIxXL3q3DBHzgFvks5sIXHmgaJpZM4OHKOv>
.
|
|
/cc |
|
Lgtm. Let's proceed with this. |
Automatic merge from submit-queue (batch tested with PRs 48480, 48353) remove tpr api access xref kubernetes#48152 TPR tentacles go pretty deep. This gets us started by removing API access and we'll move down from there. @kubernetes/sig-api-machinery-misc @ironcladlou this should free up the GC implementation since TPRs will no longer be present and failing. ```release-note Removing TPR api access per kubernetes#48152 ```
Automatic merge from submit-queue (batch tested with PRs 45467, 48091, 48033, 48498) bulk delete of tpr packages related to #48152 Bulk delete of the TPR code. I made the minimal changes outside the delete to try to keep it easy to review.
|
We need |
Makes sense. I put the release-note on that one, but forgot about the extra "action required" bit. |
Automatic merge from submit-queue (batch tested with PRs 48497, 48604, 48599, 48560, 48546) remove dead code This removes the dead code cruft since we stopped serving TPRs. ref #48152
Automatic merge from submit-queue (batch tested with PRs 48497, 48604, 48599, 48560, 48546) client-go: remove TPR example Now that the TPR api is gone (#48152).
|
This is done. |
|
I agree that this decision was well communicated, and do not wish to revert it, but I wanted to revisit it for a moment as prior art for future deprecations. Did we remove TPR's a release too early? If TPR's were actually alpha, then I think we did fine. But https://v1-6.docs.kubernetes.io/docs/api-reference/v1.6/#thirdpartyresource-v1beta1-extensions shows them as v1beta1 CRD's don't show up in the API reference docs in v1.7 https://v1-7.docs.kubernetes.io/docs/api-reference/v1.7/ Using the table listed in https://kubernetes.io/docs/reference/deprecation-policy/ as an example, it seems like we should have kept TPR's around until v1.9:
Am I misinterpreting the deprecation policy, or did we make an exception here? |
|
For the TPR's were actually alpha. They did not complete the gathered requirements for beta, and had known issues. The user guide was updated in 1.5 to indicate they were not considered stable. |
|
In addition, at the time when we did this, the Beta deprecation policy was to keep the old API around for "3 months, 1 release". It was later changed without any announcement (that I saw) to "6 months, 2 releases": kubernetes/website@8f96772#diff-20e68d228e6f9fe6ccc143526a382670R78 |
In 1.6 TPR was indicated as unstable and subject to change [1]. Near the end of 1.6 we talked about a new API and how we would transition [2]. In 1.7 we updated the docs to announce deprecation and provided the alternative and a clean semi-automatic migration path [3]. They were specifically called out in the release notes [4]. There is acknowledgement in the community that they will be removed [5], and following our deprecation policy we can remove them in 1.8 and focus our efforts on adding features like validation to CRDs.
@kubernetes/sig-api-machinery-misc @enisoc @smarterclayton @sttts @nikhita
The text was updated successfully, but these errors were encountered: