Add K_NAMESPACE env var to user-container

[savitaashture]

Fixes #6947

Proposed Changes

• Add K_NAMESPACE env to user-container

Release Note

None

[knative-prow-robot]

@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.

[knative-test-reporter-robot]

The following jobs failed:

Test name	Triggers	Retries
pull-knative-serving-integration-tests	pull-knative-serving-integration-tests	1/3

Automatically retrying due to test flakiness...
/test pull-knative-serving-integration-tests

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: savitaashture
To complete the pull request process, please assign dprotaso
You can assign the PR to them by writing /assign @dprotaso in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• pkg/apis/OWNERS
• pkg/reconciler/OWNERS
• test/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dprotaso]

I don't see any assertions of this field in the tests

[dprotaso]

So I'm curious if you need/want this

[dgerd]

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

[vagababov]

also
/cc @evankanderson

[mattmoor]

Yeah, we should be solving this via the downward API

[duglin]

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.

[mattmoor]

@duglin This PR is the tip of the iceberg. To provide the relief you want, we need to update specs / docs as well, or this isn't discoverable. Honestly, I don't think the work involved to solve #4190 would be significantly larger than the work to properly land this.

[duglin]

Maybe, but #4190 has been there since May

[mattmoor]

So help us find someone to drive that work...? :)

[vagababov]

Can we close this PR, since it seems it'll be done as part of #4190.

[knative-prow-robot]

@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.

[vagababov]

I am going to close it, since we closed the underlying bug.
/close

[knative-prow-robot]

@vagababov: Closed this PR.

In response to this:

I am going to close it, since we closed the underlying bug.
/close

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.