In that case you might have to send an updated request with “active”: false via a PUT request to /Users/:guid http://docs.cloudfoundry.org/api/uaa/version/4.11.0/#create-4

#cf

Hi Shilpa, Did you try sending a PATCH request as per the example you linked, with locked: true ? Eg PATCH /Users/0daf6e54-52c5-4360-bd4a-77f5355950b3/status HTTP/1.1 Content-Type: application/json Au

#cf

+1 for that. More flexible logic around routing to backend services would help contribute to removing the “data services in CF are so hard, let’s just use off-PaaS” view that I’ve seen a number of ent

Looks like your app_ssh_host_key_fingerprint is empty. "app_ssh_host_key_fingerprint => Expected instance of String, given an instance of NilClass"

You should probably start by looking at the cloud_controller_ng process logs in the /var/vcap/sys/log/cloud_controller_ng folder on the api_z1 VM

VCAP_SERVICES is a way to pass credentials securely to your app. A permission denied error would seem to indicate that those credentials are not getting passed correctly, or that the DFSR does not all

Hi Naresh, There used to be a workaround on the loggregator github page, but I don’t see it now. It still out there cached on sites like this: https://www.diycode.cc/projects/cloudfoundry/loggregator#

+1 for separate Service Controller And also +1 for enabling the service credential sharing via the Space Developer role. I mentioned Org Manager earlier as a poor way of saying "not the platform admin

I really like the proposal, especially in support of using messaging systems between microservices. It would be great if we could avoid reliance on central admins for enabling service sharing between

Well if you're after a hacky interim solution you could extend the buildpack & modify the start command/script to copy any heapdumps on the container file system to some shared location after Java exi

I'll echo Chip's statement - you've got to move with the CF community. In the meantime if the time period between crashes is fairly predictable, perhaps you could use something like yourkit to generat

It will be buildpack dependant. Seems like there's a plan Java-buildpack if that's what you're using: binding a volume service with tag 'heap-dump' seems to cause the heap ump to get stored on it when

Thanks Jon. The financial services clients I have worked with would also like the ability to turn on ‘cf ssh’ support in production, safe in the knowledge that app teams won’t abuse it by creating app

Hi, Last year when ‘cf ssh’ functionality was being discussed, I’m pretty sure that the concept of automatically restarting containers following an SSH session was discussed. It was to protect against

A user-provided service in CF is simply a pointer, with credentials, to some infrastructure that is itself managed outside of CF. This pointer can be created using the "CF cups" command. If you're hav

And if your apps are using an APM tool agent such as AppDynamics or NewRelic, it's likely you'd be able to invoke the JMX mbean via the APM tool GUI

Agree on all counts. We've already suggested vendoring the gems inside the buildpack to ensure they're there on the staging container. I'm now suggesting that the bin scripts just can't find the gems,

So I think your problem is that your gems are on the DEA at staging time but aren't being found by the Ruby layer, right? If so the normal approach is to point to them via an env Var (eg BUNDLE_PATH,

You could change the config/repository.yml to point to a DNS name on your network. Then build out one or more local repositories on your network using the Java-buildpack-dependency-builder: https://gi

I think you'd be better to get the gems to be deployed inside the buildpack zip & used by your buildpack bin scripts from when the zip is unpacked. Maybe you could vendor the gems as part of your 'bun