Prefix system environment variables with KNATIVE_

[dgerd]

In what area(s)?

/area API

/area autoscale
/area build
/area monitoring
/area networking
/area test-and-release

Describe the feature

We currently have three system environment variables that we prefix with K_ such as K_REVISION, K_CONFIGURATION, and K_SERVICE. It is highly likely that there will be additional environment variables we want to add in the future (K_ROUTE anyone?). As we do not allow users to specify environment variables that match system environment variables (#4050) adding a environment variable can be a breaking change to existing Services and Configurations. For example, if a user has K_FOO defined in their Service in Knative 0.6 and we decide to make K_FOO a system environment variable in Knative 0.7 the Service will begin to fail in Knative 0.7.

This proposal is to reserve a prefix for system environment variables set by Knative so that (1) we do not have to update validation for each environment variable we add and (2) we don't have to worry if adding environment variables is a breaking change. The prefix K_ is likely too short and may conflict with other applications so I propose we expand it to be KNATIVE_.

As our existing environment variables may be in use we should not remove them, but we should add a copy of them under the KNATIVE_ prefix (i.e. KNATIVE_SERVICE) so that they can be consumed consistency with future environment variables.

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[MIBc]

If env name is changed, I think the app who use these env should changed too. It may cost developer's time to do this.

[dgerd]

That is why the original issue has 'As our existing environment variables may be in use we should not remove them, but we should add a copy of them under the KNATIVE_ prefix (i.e. KNATIVE_SERVICE) so that they can be consumed consistency with future environment variables.`

This change is essentially to validate that KNATIVE_* environment variables cannot be defined within the revision template as these are 'system reserved'. It is useful if we ever decide to extend the environment variables we support, but I would rather users be able to provide their own name for a given Knative attribute. For example, instead of referencing K_REVISION in my application I would rather have an environment variable called VERSION which can use local information when running locally and the Knative Revision when running in Knative so that I do not have to hard-code Knative specific environment variables into my application.

[knative-housekeeping-robot]

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

[duglin]

/remove-lifecycle rotten

I like the idea of allowing people to make Kn values to their own env vars, but I still think there's value in having the KNATIVE_* ones too.

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[dprotaso]

/remove-lifecycle stale