Remove deprecated field and annotation

[thockin]

Remove some long-deprecated or expired fields and annotations.

Admit that the implied emptyDir behaviotr probably will never go away.

Remove the pod.spec.DeprecatedServiceAccount field, which was deprecated before v1.

Remove the service.beta.kubernetes.io/load-balancer-source-ranges annotation, which was replaced with service.spec.loadBalancerSourceRanges about a year ago.

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: thockin

Needs approval from an approver in each of these OWNERS Files:

• federation/OWNERS [thockin]
• pkg/OWNERS [thockin]
• staging/src/k8s.io/client-go/OWNERS [thockin]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[k8s-reviewable]

This change is 

[liggitt]

service account field LGTM, do we have a convention for marking dead protobuf ids we cannot use (or are we just counting on review to prevent someone from trying to fill in a gap left by a removed field in the future)?

[thockin]

will add a comment

[thockin]

I wondered that too. Google convention is to have a comment at the end of the struct, but this is all auto-gen. Do we need to leave the field here forever as a placeholder?

…

On Mon, Apr 24, 2017 at 9:45 PM, Jordan Liggitt ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In pkg/api/v1/types.go <#44900 (comment)> : > @@ -2342,11 +2342,6 @@ type PodSpec struct { // More info: http://releases.k8s.io/HEAD/docs/design/service_accounts.md // +optional ServiceAccountName string `json:"serviceAccountName,omitempty" protobuf:"bytes,8,opt,name=serviceAccountName"` - // DeprecatedServiceAccount is a depreciated alias for ServiceAccountName. - // Deprecated: Use serviceAccountName instead. - // +k8s:conversion-gen=false - // +optional - DeprecatedServiceAccount string `json:"serviceAccount,omitempty" protobuf:"bytes,9,opt,name=serviceAccount"` this LGTM, do we have a convention for marking dead protobuf ids we cannot use (or are we just counting on review to prevent someone from trying to fill in a gap left by a removed field in the future)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#44900 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVHmMi9RuYdAP2jVNUzk-ptSaoYPgks5rzXp_gaJpZM4NG_nh> .

[liggitt]

need to sweep examples/docs (at least in-tree) for use of serviceAccount: ...

[liggitt]

I wondered that too. Google convention is to have a comment at the end of the struct, but this is all auto-gen.

Never discount an enterprising (or confused) developer that manually assigns a protobuf id, not knowing the generation would do it for them.

Do we need to leave the field here forever as a placeholder?

Not live, but maybe commented out in a "removed fields" section? @smarterclayton, thoughts?

[justinsb]

Have we deprecated service.beta.kubernetes.io/load-balancer-source-ranges? I looked around, and on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the Leopard, I did find a note that said we intended to deprecate it, which will be printed if people use kubectl I believe, but that was in Dec 2016.

Also, it's a high-risk change: a service that was locked down will suddenly be opened up to everyone I believe.

I'm not even sure where we do actually deprecate things - release notes?

[smarterclayton]

The allocator is not supposed to hole fill. Let's go ahead and add a comment that indicates the deprecated ID and I'll make gengo respect it and error // +k8s:protobuf-deprecated=fieldName,ID Maybe? On Apr 25, 2017, at 12:50 AM, Jordan Liggitt <notifications@github.com> wrote: I wondered that too. Google convention is to have a comment at the end of the struct, but this is all auto-gen. Never discount an enterprising (or confused) developer that manually assigns a protobuf id, not knowing the generation would do it for them. Do we need to leave the field here forever as a placeholder? Not live, but maybe commented out in a "removed fields" section? @smarterclayton <https://github.com/smarterclayton>, thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#44900 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_p4fIEN9uMFf5gY7V0maurrrEak-Bks5rzXuHgaJpZM4NG_nh> .

[liggitt]

would be good to get this in at the beginning of 1.8

[mengqiy]

fixes: kubernetes/kubectl#23

[k8s-ci-robot]

@thockin: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
Jenkins Bazel Build	aaf46dd	link	@k8s-bot bazel test this
Jenkins unit/integration	aaf46dd	link	@k8s-bot unit test this
Jenkins verification	aaf46dd	link	@k8s-bot verify test this
Jenkins kops AWS e2e	aaf46dd	link	@k8s-bot kops aws e2e test this

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.

[thockin]

/retest

[thockin]

This is ready for review, but many of the earlier commits are already out as PRs of their own.

[liggitt]

removal of the field still LGTM, quick search of "?serviceAccount"?: still shows in-tree usage and generated files containing the old field name though

[k8s-github-robot]

@thockin PR needs rebase

[k8s-github-robot]

This PR hasn't been active in 90 days. Closing this PR. Please reopen if you would like to work towards merging this change, if/when the PR is ready for the next round of review.

cc @freehan @liggitt @thockin

You can add 'keep-open' label to prevent this from happening again, or add a comment to keep it open another 90 days