I find them useful. Thank you. Tom

Hi, Version 244 introduced changes in this area. See http://bosh.io/releases/github.com/cloudfoundry/cf-release?version=244 I didn't dig into the details. I know older versions of the cf client did no

At what version does this change occur?

cf v240, diego 0.1481.0, cflinuxfs-rootfs 1.21.0, etcd 63, garden-linux 0.339.0, bosh-openstack-kvm-ubuntu-trusty-go_agent 3262.4 With a runner instance, pushing the sample go application works fine.

I got past the api_z1 failure by adding: - name: consul_agent release: cf to the api_z1 section. I'm now confused by having to remove the other lines. I will need to test this out. Tom

AWS: light-bosh-stemcell-3232.3-aws-xen-hvm-ubuntu-trusty-go_agent vSphere: bosh-stemcell-3232.3-vsphere-esxi-ubuntu-trusty-go_agent OpenStack: N/A BOSH-Lite: bosh-stemcell-3147-warden-boshlite-ubuntu

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

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. Veritas is quite informative. I found 2 apps running and 2 crashed. I deleted them and all appears well.

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.

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

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

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

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":

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

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

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.

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

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

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!