By the `application_uris` data are broken logic, VCAP_SERVICES is also
broken and should be removed as it doesn't reflect service binding changes.

In my (strong) opinion it doesn't make any sense to run an application in a
dynamic environment and NOT expose its route(s). This has a lot of
implications. For example, an application running on Diego can no longer
register itself with a dynamic service registry since the information
needed to route to the application is totally obscured. (i.e. Spring
Cloud's integration with Eureka.)

It makes more sense to me to match the behavior of service bind/unbind by
notifying the user at route map/unmap time that they need to restart their
app for it to see the changes.

-Mike

On Wed, Sep 16, 2015 at 9:09 AM 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