Hey Mike, I think that sounds like a reasonable approach to the problem. I'm not aware of any other things that would change under that definition. Added Nick, the currently dojo-ing new PM for CAPI

Hi Hristo, Correct me if I'm wrong but it sounds like you are calling purge multiple times. Am I misunderstanding the work flow you are describing? Purge should only be called only one time EVER on

Indeed I scripted a couple of « bosh create release » / « bosh upload release » and then bosh-workspace is happy with it. It worked like a charm. Buildpacks just end up being there, automatically

I did cd cf-release git fetch origin git checkout develop git pull --ff-only ./scripts/update bosh create release --with-tarball And also cd src/buildpacks/binary-buildpack-release/ git fetch

And btw Amit, it looks like the java-buildpack v3.6 is here with its

No no no, these are not SHAs of cf-release, but those of all the buildpack-releases indeed. Looks like no blobs of these releases are actually available online, are they? I'm running the standard

Sorry for the late response. I didn't get a chance to try again until today. It turned out by setting require_https to false will let me run "cf login". Properties uaa + require_https:

At the time of the email, the java buildpack hadn't been extracted into a separate release yet. I believe it has now, and that will be reflected in CF v232. What command did you run? What SHA of

Amit, just for me to be sure, why didn’t you list the java-buildpack? Also, have the blobs properly been uploaded? I copy below the BOSH errors I get: With binary-buildpack: Uploading

Hi Ning, 1) I think you'd better open another terminal and run `cf logs (appname)` while pushing your app. 2) If you know something about buildpacks (especially about the 3 major steps -- detect,

Yes, it's one way but it's not flexible, and scale app need to restart the app as well. As I said I may have some heavy operations which will definitely need more than 2G. In my opinion the ideal way

Thanks for the answer Marco! (I realize I'm much influenced by the Percona vision, because they are active here in Paris dev communities.) I finally upgraded to v26 and well.. Congratulations for the

I suggest you manually “cf scale -m 2G“ after your app has booted. Type “cf scale --help” for more info.

That's right Amit, but it was just a typo by me. I meant setting instances counts to zero for “runner_z*” and “hm9000_z*”. I saw in a-detailed-transition-timeline that those two properties

Thanks everyone. What I understood from Amit's response is that I can parallelize certain components. What I also understood from both Amit's and Dieu's responses is that some components have hard

Hi, In which file I have to add below properties After adding below properties, it works now： app_ssh: host_key_fingerprint: a6:d1:08:0b:b0:cb:9b:5f:c4:ba:44:2a:97:26:19:8a oauth_client_id:

You need the api jobs, those are the cloud controllers! Set the runner and hm9000 jobs to 0 instances, or even remove them from your deployment manifest altogether. wrote:

Hi Dieu, We are polling app-usage-events with Abacus, but because of purge the events may be out of order right after billing epoch started. But that's only part of the problem. To consume

Hi cf-dev, For a fresh new deployment of cf-release <https://github.com/cloudfoundry/cf-release>, I wonder how the default manifests stubs and templates should be modified to remove unnecessary

It should also be considered that in some scenarios the order of deployment as recommended serially will most often be the most tested in terms of ensuring backwards compatibility of code changes