Environment variable names (was RE: Environment variable changes in DIEGO)


john mcteague <john.mcteague@...>
 

On a related, but slightly off, topic, while renaming the VCAP_* vars would
have a big impact, is it not time we thought about renaming these to CF_* ?

John.

On 16 Sep 2015 16:09, "Matthew Sykes" <matthew.sykes(a)gmail.com> wrote:

The changes, in general, were intentional. The `application_uris` data was
always broken as it didn't reflect route changes. I can't speak directly to
the time stamp data.

The host is present still so I don't know why you don't see it.

We also have a migration guide [1]. If you think additional information is
needed there, pull requests would be welcome.

[1]:
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md

On Wed, Sep 16, 2015 at 10:19 AM, Jack Cai <greensight(a)gmail.com> wrote:

I notice the below changes in the environment variables of DIEGO:
1. VCAP_APP_HOST & VCAP_APP_PORT are removed.
2. These fields are removed from VCAP_APPLICATION value:
application_uris, started_at, start, started_at_timestamp, host,
state_timestamp

I suppose #1 is intentional. How about #2?

Jack


--
Matthew Sykes
matthew.sykes(a)gmail.com


Onsi Fakhouri <ofakhouri@...>
 

Would if we could! Environment variables are part of the surface area that constitutes the contract between the platform and the application. While we could have duplicates with CF_* and eventually deprecate VCAP_* the new runtime needs to support droplets staged by the legacy runtime seamlessly.

Once the dust settles I'd sooner see us step back and reconsider this particular abstraction. For example, instead of env vars an authenticated metadata service a la AWS's http://169.254.169.254/ would give us more flexibility, allow us to dynamically control metadata made available to apps, and even version metadata sanely.

Onsi

Sent from my iPad

On Sep 16, 2015, at 8:30 AM, john mcteague <john.mcteague(a)gmail.com> wrote:

On a related, but slightly off, topic, while renaming the VCAP_* vars would have a big impact, is it not time we thought about renaming these to CF_* ?

John.

On 16 Sep 2015 16:09, "Matthew Sykes" <matthew.sykes(a)gmail.com> wrote:
The changes, in general, were intentional. The `application_uris` data was always broken as it didn't reflect route changes. I can't speak directly to the time stamp data.

The host is present still so I don't know why you don't see it.

We also have a migration guide [1]. If you think additional information is needed there, pull requests would be welcome.

[1]: https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md

On Wed, Sep 16, 2015 at 10:19 AM, Jack Cai <greensight(a)gmail.com> wrote:
I notice the below changes in the environment variables of DIEGO:
1. VCAP_APP_HOST & VCAP_APP_PORT are removed.
2. These fields are removed from VCAP_APPLICATION value: application_uris, started_at, start, started_at_timestamp, host, state_timestamp

I suppose #1 is intentional. How about #2?

Jack


--
Matthew Sykes
matthew.sykes(a)gmail.com


Christopher B Ferris <chrisfer@...>
 

Onsi,
 
I can tell you that we (IBM) would welcome a secure metadata service for retrieving credentials, etc. I'm sure we'd help make that happen.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402
 
 

----- Original message -----
From: Onsi Fakhouri <ofakhouri@...>
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Cc:
Subject: [cf-dev] Re: Environment variable names (was RE: Environment variable changes in DIEGO)
Date: Wed, Sep 16, 2015 11:40 AM
 
 
Would if we could!  Environment variables are part of the surface area that constitutes the contract between the platform and the application.  While we could have duplicates with CF_* and eventually deprecate VCAP_* the new runtime needs to support droplets staged by the legacy runtime seamlessly.
 
Once the dust settles I'd sooner see us step back and reconsider this particular abstraction.  For example, instead of env vars an authenticated metadata service a la AWS's http://169.254.169.254/ would give us more flexibility, allow us to dynamically control metadata made available to apps, and even version metadata sanely.
 
Onsi

Sent from my iPad

On Sep 16, 2015, at 8:30 AM, john mcteague <john.mcteague@...> wrote:
 

On a related, but slightly off, topic, while renaming the VCAP_* vars would have a big impact, is it not time we thought about renaming these to CF_*  ?

John.

On 16 Sep 2015 16:09, "Matthew Sykes" <matthew.sykes@...> wrote:
The changes, in general, were intentional. The `application_uris` data was always broken as it didn't reflect route changes. I can't speak directly to the time stamp data.
 
The host is present still so I don't know why you don't see it.
 
We also have a migration guide [1]. If you think additional information is needed there, pull requests would be welcome.
 
 
On Wed, Sep 16, 2015 at 10:19 AM, Jack Cai <greensight@...> wrote:
I notice the below changes in the environment variables of DIEGO:
1. VCAP_APP_HOST & VCAP_APP_PORT are removed.
2. These fields are removed from VCAP_APPLICATION value: application_uris, started_at, start, started_at_timestamp, host, state_timestamp
 
I suppose #1 is intentional. How about #2?
 
Jack
 
 
 
--
Matthew Sykes
matthew.sykes@...
 


Mike Youngstrom
 

+1 We'd love a metadata service as well when the dust settles.

Mike

On Wed, Sep 16, 2015 at 1:17 PM, Christopher B Ferris <chrisfer(a)us.ibm.com>
wrote:

Onsi,

I can tell you that we (IBM) would welcome a secure metadata service for
retrieving credentials, etc. I'm sure we'd help make that happen.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402



----- Original message -----
From: Onsi Fakhouri <ofakhouri(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Cc:
Subject: [cf-dev] Re: Environment variable names (was RE: Environment
variable changes in DIEGO)
Date: Wed, Sep 16, 2015 11:40 AM


Would if we could! Environment variables are part of the surface area
that constitutes the contract between the platform and the application.
While we could have duplicates with CF_* and eventually deprecate VCAP_*
the new runtime needs to support droplets staged by the legacy runtime
seamlessly.

Once the dust settles I'd sooner see us step back and reconsider this
particular abstraction. For example, instead of env vars an authenticated
metadata service a la AWS's http://169.254.169.254/ would give us more
flexibility, allow us to dynamically control metadata made available to
apps, and even version metadata sanely.

Onsi

Sent from my iPad

On Sep 16, 2015, at 8:30 AM, john mcteague <john.mcteague(a)gmail.com>
wrote:


On a related, but slightly off, topic, while renaming the VCAP_* vars
would have a big impact, is it not time we thought about renaming these to
CF_* ?

John.
On 16 Sep 2015 16:09, "Matthew Sykes" <matthew.sykes(a)gmail.com> wrote:

The changes, in general, were intentional. The `application_uris` data was
always broken as it didn't reflect route changes. I can't speak directly to
the time stamp data.

The host is present still so I don't know why you don't see it.

We also have a migration guide [1]. If you think additional information is
needed there, pull requests would be welcome.

[1]:
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md

On Wed, Sep 16, 2015 at 10:19 AM, Jack Cai <greensight(a)gmail.com> wrote:

I notice the below changes in the environment variables of DIEGO:
1. VCAP_APP_HOST & VCAP_APP_PORT are removed.
2. These fields are removed from VCAP_APPLICATION value: application_uris,
started_at, start, started_at_timestamp, host, state_timestamp

I suppose #1 is intentional. How about #2?

Jack




--
Matthew Sykes
matthew.sykes(a)gmail.com




john mcteague <john.mcteague@...>
 

Add another +1. We are implementing something akin to this within out
environment, having it standardised would be a big win.

On Wed, Sep 16, 2015 at 8:49 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

+1 We'd love a metadata service as well when the dust settles.

Mike

On Wed, Sep 16, 2015 at 1:17 PM, Christopher B Ferris <chrisfer(a)us.ibm.com
wrote:
Onsi,

I can tell you that we (IBM) would welcome a secure metadata service for
retrieving credentials, etc. I'm sure we'd help make that happen.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402



----- Original message -----
From: Onsi Fakhouri <ofakhouri(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Cc:
Subject: [cf-dev] Re: Environment variable names (was RE: Environment
variable changes in DIEGO)
Date: Wed, Sep 16, 2015 11:40 AM


Would if we could! Environment variables are part of the surface area
that constitutes the contract between the platform and the application.
While we could have duplicates with CF_* and eventually deprecate VCAP_*
the new runtime needs to support droplets staged by the legacy runtime
seamlessly.

Once the dust settles I'd sooner see us step back and reconsider this
particular abstraction. For example, instead of env vars an authenticated
metadata service a la AWS's http://169.254.169.254/ would give us more
flexibility, allow us to dynamically control metadata made available to
apps, and even version metadata sanely.

Onsi

Sent from my iPad

On Sep 16, 2015, at 8:30 AM, john mcteague <john.mcteague(a)gmail.com>
wrote:


On a related, but slightly off, topic, while renaming the VCAP_* vars
would have a big impact, is it not time we thought about renaming these to
CF_* ?

John.
On 16 Sep 2015 16:09, "Matthew Sykes" <matthew.sykes(a)gmail.com> wrote:

The changes, in general, were intentional. The `application_uris` data
was always broken as it didn't reflect route changes. I can't speak
directly to the time stamp data.

The host is present still so I don't know why you don't see it.

We also have a migration guide [1]. If you think additional information
is needed there, pull requests would be welcome.

[1]:
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md

On Wed, Sep 16, 2015 at 10:19 AM, Jack Cai <greensight(a)gmail.com> wrote:

I notice the below changes in the environment variables of DIEGO:
1. VCAP_APP_HOST & VCAP_APP_PORT are removed.
2. These fields are removed from VCAP_APPLICATION value:
application_uris, started_at, start, started_at_timestamp, host,
state_timestamp

I suppose #1 is intentional. How about #2?

Jack




--
Matthew Sykes
matthew.sykes(a)gmail.com