Hi CF,

CAPI would like to introduce a validation where we disallow environment
variables that begin with “CF_”. For context, we already [1] have several
validations for environment variables, e.g. “VCAP_”. We would like to
prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_” that
are already set in containers running on the platform. Currently, without
this validation, users can override these with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where apps
can be made up of multiple processes and tasks. See [2] original discussion
and [3] proposed environment variables we will introduce as we roll out the
V3 API.


If this is acceptable, we’d like to propose adding this validation in an
upcoming version of Cloud Foundry. The plan might look something like this:

1. Announce that the validation would be added in a certain version of
Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION, say
completion of above story + 5 versions.



Please let us know if you have any feedback for the validation itself or
the plan to roll this out.

Thanks!

Nick


[1]
https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/messages/validators.rb#L41-L47
[2]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
[3] https://www.pivotaltracker.com/story/show/126180869

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

That plan sounds good to me. I'd only ask that we attempt to lock down how
long we are going to keep VCAP_APPLICATION around sooner than later. It
will take time for our customers to transition their application to the new
variable and our customers work off of time schedules not X number of CF
releases. I'd like to see VCAP_APPLICATION stay around for at least 3
months after the new variable is available.

Mike

On Tue, Nov 29, 2016 at 1:40 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF,

CAPI would like to introduce a validation where we disallow environment
variables that begin with “CF_”. For context, we already [1] have several
validations for environment variables, e.g. “VCAP_”. We would like to
prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_” that
are already set in containers running on the platform. Currently, without
this validation, users can override these with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where apps
can be made up of multiple processes and tasks. See [2] original discussion
and [3] proposed environment variables we will introduce as we roll out the
V3 API.


If this is acceptable, we’d like to propose adding this validation in an
upcoming version of Cloud Foundry. The plan might look something like this:

1. Announce that the validation would be added in a certain version of
Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION, say
completion of above story + 5 versions.



Please let us know if you have any feedback for the validation itself or
the plan to roll this out.

Thanks!

Nick


[1] https://github.com/cloudfoundry/cloud_controller_
ng/blob/master/app/messages/validators.rb#L41-L47
[2] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.
cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#
LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
[3] https://www.pivotaltracker.com/story/show/126180869

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

I vote that VCAP_APPLICATION not be removed.
While it is nice that we want to replace certain environment variables,
these have been there since day one. Asking people to rewrite their
applications is just wrong.

I do not see how we are tying a programming model discussion with an API
version. If we want to change the programming model of CF, then document
what the programming model is currently, and provide a way for people to
opt in to this new model. But I would certainly hope it is more than
just twiddling environment variables. A silly change will cause a lot of
pain.

- Michael

CF seems like it could be used as a prefix for a number of apps outside the
ecosystem. Would it be better to specifically exclude the full CF strings
in question rather than a CF_* wildcard?

Tim

On Tue, Nov 29, 2016 at 8:40 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF,

CAPI would like to introduce a validation where we disallow environment
variables that begin with “CF_”. For context, we already [1] have several
validations for environment variables, e.g. “VCAP_”. We would like to
prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_” that
are already set in containers running on the platform. Currently, without
this validation, users can override these with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where apps
can be made up of multiple processes and tasks. See [2] original discussion
and [3] proposed environment variables we will introduce as we roll out the
V3 API.


If this is acceptable, we’d like to propose adding this validation in an
upcoming version of Cloud Foundry. The plan might look something like this:

1. Announce that the validation would be added in a certain version of
Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION, say
completion of above story + 5 versions.



Please let us know if you have any feedback for the validation itself or
the plan to roll this out.

Thanks!

Nick


[1] https://github.com/cloudfoundry/cloud_controller_
ng/blob/master/app/messages/validators.rb#L41-L47
[2] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.
cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ/#
LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
[3] https://www.pivotaltracker.com/story/show/126180869

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

-1

I think VCAP_APPLICATION should not be removed. Seems like it would break
alot of tools or scripts depending on it.

On Tue, Nov 29, 2016 at 4:41 PM, Tim Lawrence <tim.lawrence1984(a)gmail.com>
wrote:

CF seems like it could be used as a prefix for a number of apps outside
the ecosystem. Would it be better to specifically exclude the full CF
strings in question rather than a CF_* wildcard?

Tim

On Tue, Nov 29, 2016 at 8:40 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF,

CAPI would like to introduce a validation where we disallow environment
variables that begin with “CF_”. For context, we already [1] have several
validations for environment variables, e.g. “VCAP_”. We would like to
prohibit “CF_” for a couple reasons:

1. There are several environment variables with the prefix “CF_” that
are already set in containers running on the platform. Currently, without
this validation, users can override these with app environment variables.
2. VCAP_APPLICATION doesn’t quite fit for the V3 API world where apps
can be made up of multiple processes and tasks. See [2] original discussion
and [3] proposed environment variables we will introduce as we roll out the
V3 API.


If this is acceptable, we’d like to propose adding this validation in an
upcoming version of Cloud Foundry. The plan might look something like this:

1. Announce that the validation would be added in a certain version
of Cloud Foundry.
2. Complete the [3] story for the new “CF_” environment variables.
3. Announce the version where we will remove VCAP_APPLICATION, say
completion of above story + 5 versions.



Please let us know if you have any feedback for the validation itself or
the plan to roll this out.

Thanks!

Nick


[1] https://github.com/cloudfoundry/cloud_controller_ng/
blob/master/app/messages/validators.rb#L41-L47
[2] https://lists.cloudfoundry.org/archives/list/cf-dev@
lists.cloudfoundry.org/thread/LTF4NAKWF56SEER57ZNBO5SLM72NPT
QJ/#LTF4NAKWF56SEER57ZNBO5SLM72NPTQJ
[3] https://www.pivotaltracker.com/story/show/126180869

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

Thanks for the feedback, I’ve gotten enough push back to shelve this. We’ll
reconsider how to expose some of the [1] new V3 information proposed in
this story.

[1] https://www.pivotaltracker.com/n/projects/966314/stories/126180869

--
Nicholas Calugar