Christopher B Ferris <chrisfer@...>
toggle quoted messageShow quoted text
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.
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
phone: +1 508 667 0402
----- Original message -----
From: Onsi Fakhouri <ofakhouri@...>
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
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.
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_* ?
On 16 Sep 2015 16:09, "Matthew Sykes" <matthew.sykes@...
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 . 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@...>
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?