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.
toggle quoted message
Show quoted text
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
toggle quoted message
Show quoted text
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
toggle quoted message
Show quoted text
----- 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 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
--
|
|
Mike Youngstrom <youngm@...>
+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.
toggle quoted message
Show quoted text
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
|
|