Re: cf-release v208 is now available

Dieu Cao <dcao@...>

Regarding manifest templates, this means that the bosh director can now
look at the number of instances per job to calculate the resource pool
sizes so it does not need to be specified separately.
As of version 2862, BOSH can compute these sizes dynamically from the list
of jobs. Let's remove this data from the spiff templates in cf-release.
You will need at least this version of BOSH.
I'll update the release note to mention that.

Regarding ephemeral disk sizes, it's not required to use underscores. The
4GB specified in the template for c3.large is replacement of the ephemeral
disk used by default for c3.large.
Also, there was an additional commit [1] that adjusted the instances sizes
back up a bit as we were seeing flakiness in our environments when it was
too low.
I'll link that commit too on the release notes.



On Tue, May 12, 2015 at 6:41 PM, John Wong <gokoproject(a)> wrote:

Great release!!! Congrat.

Just a couple questions (but if this is the right thread to ask please
excuse me and let me know).

- Manifest templates no longer include resource pool sizes details

In a way I was "spoiled" and never really asked why we needed resource
pool but went alone with it, but what does the commit comment "bosh
director can figure this out automatically" mean?

- Adjusted ephemeral disk sizes on new instance types for AWS template
to be more realisticdetails

I just want to make sure I understand the underscore for each of the size
is just some syntax thing for the template, not something I would actually
write in my manifest. Also c3.large by default has 2x16SSD, so are we
taking 4Gb (from the template) from the ephemeral/instance?

And congratulation for merging UAA and Login server. So now all we need is
2 VMs minimally if we really want to have HA (aside from enabling
bosh resurrect).

Thanks in advance.

John Wong

On Tue, May 12, 2015 at 8:22 PM, Dieu Cao <dcao(a)> wrote:

The cf-release v208 was released on May 12th, 2015

- Please see note about merge of UAA/Login server jobs below to
maintain zero down time for CC and UAA for existing deployments.


- [Experimental] Work continues on support for Asynchronous Service
Instance Operationsdetails
- Completed Improvements to Recursive Deletion of Org and Space, in
support of Asynchronous Service Operations details
- [Experimental] Work continues on /v3 and Application Process Types
details <>
- [Experimental] Work continues on Route API details
- [Experimental] Work continues on Context Path Routes details
- Work continues on support for Service Keys details
- Work continues on support for Arbitrary Service Parameters details
- Adjusted ephemeral disk sizes on new instance types for AWS
template to be more realisticdetails
- Including staticfile buildpack v1.0.0 details
- Removed separate login job from minimal aws deployment details
- Allow acceptance test timeouts to be set via manifest details
- Update default cipher list for haproxy and gorouter details
- Addressed tcpdump CVE-2015-0261, CVE-2015-2153, CVE-2015-2154,
- Upgrading php buildpack to v3.1.1 details
- Manifest templates no longer include resource pool sizes details
- Upgrading ruby buildpack to v1.3.1 details
- Bump CLI to 6.11.1 for CATS and remove darwin CLI details
- Upgrade cf-release to use ruby 2.1.6 and remove ruby 2.1.4 for CC,
Collector, Warden, DEAdetails
- Addresses ruby CVE-2015-1855
- cloudfoundry/cf-release #660
<>: Add security
group for cf-mysql subnets to bosh-lite details
- Adjust VCAP_ID as endpoint/sticky cookie changes details
- Disable compression when creating proxy connection details
- cleanup regex details
- A space developer can create a wildcard route for private domains
details <>
- Allow commands to be reset to nothing details

UAA Updates

- Merged UAA & Login Server details
- Multi-tenant UAA details
- Registering wildcard routes for *.login and *.uaa details
- Zero Downtime Upgrade Procedure
- Perform the cf-release upgrade and keep number of login server
of jobs the same as your existing deploy.
- Change the number of Login Server Job instances to 0 and
re-deploy after initial deploy completes.

Note: The combination of Older Login Server jobs and the newly merged
UAA/Login Server job is not supported. This should be done only for a short
duration to achieve the zero downtime. The Login Server instances should be
deleted via a bosh redeploy immediately after a successful upgrade
Used Configuration

- BOSH Version: 152
- Stemcell Version: 2889
- CC Api Version: 2.25.0

Commit summary
Compatible Diego Version

- final release 1198 commit

cf-dev mailing list

Join { to automatically receive all group messages.