Hi, I wish to confirm, diego(v0.1441.0) only pulls from v2 registry now and not backward compatible with v1? What diego version switched out versions? Thanks, Tom

A 0.1441.0 install without the docker cache, pulled from a private registry, no auth, no problems. I'm confused by this thread.

CF: 225 Diego: 0.1441.0 Default to diego. I deploy a sample app, no problems. I attempt to deploy another app that fails, because of application issues. A deploy of any other app fails with: 2016-01-1

Thanks for the pointer. Now the problem: garden.stdout.log: {"timestamp":"1453002747.400245667","source":"garden-linux","message":"garden-linux.pool.acquire.provide-rootfs- failed","log_level":2,"data

cf 225, diego 0.1446.0, etcd 22, garden-linux 0.330.0 Deployed fine. Log in with admin, no problems. cf create-user -- works, user can login cf set-org-role or cf set-space-role -- "Server error, stat

Thanks for following up. I recently found a mention of TMPDIR issue and deployed the latest diego with v0.330.0. Appears to have resolved the issue. Tom

Great timing. I compared the manifest to a working revision and discovered the url after spring_profiles: was incorrect. Corrected and redeployed allowed for setting of roles. Thank you!

Openstack, cf 230 Following a manifest for 225, routing-api is part of the api_z instance. Generating the manifest for 230, routing-api is not included. Following on what worked, I added it. Api would

Why are you looking forward to independent releases? A single release option appears pretty straightforward. Single release that includes the correct dependent versions. What are the advantages of bre

I have used xip.io and ran into random errors such as this. Using a name and dns resolved them. I narrowed it down that the xip name failed to resolve at some time or another, for whatever reason.

I'm glad to see this question. Why does a space manager role not include all space developer permissions?

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0 Default to diego true. Developer deployed a java application. Deleted the application: cf delete <app> No errors. The app still responds. The only

JT, Thanks for responding. This is a test runtime and small. I checked all orgs and spaces. No routes matching the app. Found the route information and the result: { "total_results": 0, "total_pages":

The route still exists. I was reluctant to delete it and have the "app" still running. I wanted some way to track it down, not that it has helped, other than let me know it is still running. Pushed th

CF 230 Developer get error above for an existing application. I check another application, same error. I deploy a new application successfully, same error. bosh vms look fine. bosh cck looks fine. cf

Would solution 2 allow/work with a system domain? Solution #2 means api.domain is now taken so there could be no other app deployed to api.domain. Application developers may not be happy with the limi

Tracked down the issue, route_emitter instance had disappeared. Reviewing https://docs.cloudfoundry.org/concepts/diego/diego-components.html bosh vms of diego deployment, did not list a route_emitter.

Thank you. Veritas is quite informative. I found 2 apps running and 2 crashed. I deleted them and all appears well.

Yes, the logs are there. I grepped the logs for error. I see a lot of: {"timestamp":"1460161846.254659176","source":"nsync-bulker","message":"nsync-bulker.sync.not-bumping-freshness-because-of","log_l

Thank you, Eric. The query into auth_username and password, prompted me to review the manifest. Those were not correct and a typo in the cc_uploader, cc, base_url. I've made the corrections. I likely