Change:
} var map_Binding = map[string]string{ <del> "":         "Binding ties one object to another. For example, a pod is bound to a node by a scheduler.", </del> <ins> "":         "Binding ties one object to another; for example, a pod is bound to a node by a scheduler. Deprecated in 1.7, please use the bindings subresource of pods instead.", </ins> "metadata": "Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata", "target":   "The target object that you want to bind to the standard object.", }

Discussion:
Forked from We need to update the scheduler (ours and mesos) to use pods/binding instead of /binding and then we can delete /binding.
cc
This is about the top-level resource, not the subresource.
This is where mesos is using binding as top level resource: We need to change that to Resource("pods").Subresource("bindings")
/cc
If we turn this off in 1.2, will that be a problem for you?
Did we announce we were going to remove this API? Don't we need to have a process for taking it away?
Yes it would be problematic unless our scheduler was updated to use whatever was replacing it. AFAICT even the core scheduler is still using /bindings: , Clayton Coleman wrote:
Kicking this can down the road.
We should mark this deprecated.
According to , kube-mesos refactor will use HTTPExtender, so it's a not big issue to kube-mesos. But for k8s, I think scheduler is using API now ().
/assign
/close I'm going to close this; if any comments, please let me know.
We need to actually mark the endpoint deprecated so we can remove it.
OK, got that; need to deprecate it for other user. I think k8s can handle it to use .
, can you help to remove ? it's not related with Mesos anymore. I'll create a PR to deprecate .
Reopening since that PR just a deprecation warning. We still need to remove the API.
wow, agree. , would you help to remove milestone? We will not remove API in 1.7 or 1.8; but I'll trace that.
Done
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen
18 still have.
21 still have the resource. Is anyone already working on it or is there a reason why the binding resource still get served?

not entirely sure if i'm right, but from my current assumption it seems that there isn't an implementation for the for pods (xref: ) and we still use the generic resource for pods (). The resource is deprecated since 1.7 but i don't see any further progress :thinking: () dump of an :
what is the progress with this issue? Is it a backlog item that is tracked by sig scheduling?
I'm not aware of this issue. We will put it into our sig meeting to discuss.
we went through this in today's scheduling meeting. We're ok with shifting v1.Binding to pod's subresource. Before acting on it, there are several factors we need to consider: impact to external integrators - either 3rd-party scheduler or scheduler plugins (using extension point). Follow the conventional API deprecation/removal guide/process to ensure a smooth migration. overall volume of efforts. In addition to scheduling efforts, are there any API Server side efforts that need to be tweaked as well? we need to get +1 from
Is there a summary of why moving this API is necessary given that is has been around for quite sometime now? Is it related to RBAC?
/binding is a v1 API, and as such, deletion is not permitted. It can be marked deprecated, and users pointed to pods/binding by documentation as the preferred method, but not removed.
It's more to pay the technical debt. Given the action "binding" is performed against pods, composing a pod/binding instead of v1.Binding makes more sense. Thanks for clarification we cannot remove v1 APIs.
ok, thanks for the clarification, so this is not enabling a new use case, only a cleanup.
Right, and due to the stable API compatibility guarantees, I don't think it's a cleanup we can do. /close
Closing this issue. <detailsIn response to : so this is not enabling a new use case, only a cleanup. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Sorry for the late comment on this but i was AFK for a longer time. I'm not sure if we missed something. Currently there is only the implementation.

via the the API endpoint exists but it refers to the only existing kind (could be checked via ): As there isn't a seperate implementation for IMO we should remove the deprecation warning as we don't have an alternative implementation for that in place. / WDYT?