-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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.
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
Add K_NAMESPACE env var to user-container #7086
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@savitaashture: 0 warnings.
In response to this:
Fixes #6947
Proposed Changes
- Add K_NAMESPACE env to user-container
Release Note
None
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.
1996331
to
100be02
Compare
The following jobs failed:
Automatically retrying due to test flakiness... |
100be02
to
cc4498d
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: savitaashture The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@@ -32,6 +32,7 @@ type ResourceNames struct { | |||
Route string | |||
Revision string | |||
Service string | |||
Namespace string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any assertions of this field in the tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I'm curious if you need/want this
Related to #4190 Personally I would rather see namespace offered through the downward API shape than introduce it as another K_ variable. It has the benefit of letting the user specify the EnvVar they expect in their application making it more portable. cc @mattmoor |
also |
Yeah, we should be solving this via the downward API |
Until #4190 is done would it hurt to offer this as it at least provides some relief today?
…Sent from my iPad
On Feb 28, 2020, at 12:38 PM, Dan Gerdesmeier ***@***.***> wrote:
Related to #4190
Personally I would rather see namespace offered through the downward API shape than introduce it as another K_ variable. It has the benefit of letting the user specify the EnvVar they expect in their application making it more portable. metadata.namespace is the same on the Service/Configuration as it is on the Pod making the fieldRef for this particular use-case of fieldRef fairly natural.
cc @mattmoor
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Maybe, but #4190 has been there since May |
So help us find someone to drive that work...? :) |
Can we close this PR, since it seems it'll be done as part of #4190. |
@savitaashture: PR needs rebase. 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 am going to close it, since we closed the underlying bug. |
@vagababov: Closed this PR. In response to this:
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. |
Fixes #6947
Proposed Changes
Release Note