When the cloud controller instances come up, they install any buildpacks configured in the manifest. If you want a buildpack NOT to be replaced automatically (because you've updated it yourself), you'

Currently there is no way to use a single bucket with prefixes for the different blobstores. In theory you could point them all at the same bucket and nothing would break, but you'd probably regret th

Hmm, we're not seeing any problems like that, and really we're just running some git commands. I would assume that running the script does create a lot of connections in a short amount of time. Is it

Hi, What version of the cf cli are you using? There was an update for logging in cf v208 that changed the endpoint. Thanks, Joseph & Dan, OSS Release Integration Team

I see some differences in the submodules you are getting vs what is currently on cf-release dev or master branches. Which branch, tag, or SHA are you trying to check out? Joseph & Dies OSS Release Int

You might get some answers by querying the events api. http://apidocs.cloudfoundry.org/214/events/list_all_events.html You should be able to query it where the actee equals the guid of the app. Joseph

Piotr, The timestamps not being correct is a known limitation of how events are being generated, but as you said, order should be guaranteed (and timestamps should hopefully be close). Duplicate event

The Cloud Controller schedules a job to delete the buildpack from the blobstore. The job is scheduled for cc.staging_timeout_in_seconds in the future. This gives any apps that have already started sta

Hi Stephen, The consul.agent.servers.lan array should be populated with the static IPs of every consul server job you have deployed. That being said, none of this will work if you have not colocated a

The app you are pushing is not being detected as a valid Python app by the buildpack. The buildpack expects there to be a setup.py file in the root of the app if you do not provide a requirements.txt.

The buildpacks didn't successfully upload, so you'll probably just need to "bosh restart api_z1/0" which should cause the startup script to upload them. Joseph CF Release Integration Team

Yeah, without the NAT vm nothing will be able to get out to the internet. They will be able to respond to external requests, such as a request to the api, or the login server, or an individual app. Bu

It looks like the api instance is unable to upload the buildpacks to the blobstore. Perhaps the NAT (network NAT, not message bus NATS) instance is not configured correctly. Are you able to curl an ex

Also Stephen, the templates by default attempt to use an ELB named cfrouter. So if you want to try to use an ELB again, just create one with that name and when you deploy BOSH should connect it to you

The app_usage_events endpoint was not designed to be a live billing interface. Typically what you would do is have another app that polls the endpoint, collects the billing data, and saves it off in a

No, there are no special scripts that run on job instance creation, everything is embedded in the startup control scripts. So while recreate would work too, restart should be fine. Joseph OSS Release

If you are using the default postgres job, you should just be able to "bosh restart postgres_z1/0". This will create both the databases, but they will not have the schemas. The individual jobs should

Set CF_TRACE=true to see the exact request that results in the 404. Most likely it is a request to api.cf.fxlab.net/v2/info. Double check that that url does in fact return a 404. From there, the probl

Simply deleting the schema_migrations table entries may allow the api to start, but the actual changes from those migrations will need to be rolled back manually too. Best thing is certainly to backup

I believe that those limits would only need to be increased if you have more than 256 warden containers on a single server. Is that the case? Joseph & Zak CF Runtime Team wrote: