Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Default PodSpec.enableServiceLinks to false #92226

Closed
dprotaso opened this issue Jun 17, 2020 · 8 comments
Closed

Default PodSpec.enableServiceLinks to false #92226

dprotaso opened this issue Jun 17, 2020 · 8 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/node Categorizes an issue or PR as relevant to SIG Node.

Comments

@dprotaso
Copy link
Contributor

What would you like to be added:
I would like the default for enableServiceLinks to be changed from true to false

Why is this needed:

I think the default behaviour is unexpected for new users. Having this be an opt-in feature may be more predictable.

References:
#60099
elastic/cloud-on-k8s#2030
knative/serving#6074
https://stackoverflow.com/questions/45323958/is-it-possible-to-disable-service-discovery-with-environment-variables-in-kubern
https://twitter.com/fredbrancz/status/1201937181230686208
@dprotaso dprotaso added the kind/feature Categorizes issue or PR as related to a new feature. label Jun 17, 2020
@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Jun 17, 2020
@dprotaso
Copy link
Contributor Author

Dunno where PodSpec falls - best guess is

/sig api-machinery

@k8s-ci-robot k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jun 17, 2020
@liggitt
Copy link
Member

liggitt commented Jun 17, 2020

/remove-sig api-machinery
/sig node

Thanks for the request, but changing defaults in an existing API is not backwards compatible, and changing this particular default would break many existing users. Our compatibility guarantees are intended to keep existing API versions operating in backwards compatible ways.

@liggitt liggitt closed this as completed Jun 17, 2020
@k8s-ci-robot k8s-ci-robot added sig/node Categorizes an issue or PR as relevant to SIG Node. and removed sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. labels Jun 17, 2020
@dprotaso
Copy link
Contributor Author

Is there an umbrella PodSpec v2 issue that's tracking potential future changes?

@liggitt
Copy link
Member

liggitt commented Jun 17, 2020

#8190 is the closest thing I know of

@dprotaso dprotaso mentioned this issue Jun 17, 2020
Closed
@dprotaso
Copy link
Contributor Author

@liggitt Can we re-open this issue - it seems like service links will degrade pod start time even when there's a modest # of services in a namespace.

Context: knative/serving#8498 (comment)

@mattmoor
Copy link
Contributor

It's actually worse than that. Above a certain number of services new pods will fail to start altogether.

@liggitt
Copy link
Member

liggitt commented Jun 29, 2020 •
edited
Loading

@liggitt Can we re-open this issue - it seems like service links will degrade pod start time even when there's a modest # of services in a namespace.

A distinct issue tracking performance problems or startup issues (and mitigations with very large numbers of services) would be fine, but changing the default for core/v1 isn't really an option... it would break far more current users.

@dprotaso
Copy link
Contributor Author

Sounds good

@dprotaso dprotaso mentioned this issue Jun 29, 2020
Closed
@salanki salanki mentioned this issue Oct 20, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/node Categorizes an issue or PR as relevant to SIG Node.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dprotaso @liggitt @mattmoor @k8s-ci-robot