"RUNTIME-buidpack"

is the missing L intentional in buildpack?

On Thu, Mar 3, 2016 at 10:51 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey all,

Forgot to include in the original email, you will also need to update
your cc.install_buildpacks property because the packages names have also
changed for all the buildpacks (except Java). They've gone from
"buildpack_RUNTIME" to "RUNTIME-buidpack".

Best,
Amit

On Sun, Feb 21, 2016 at 4:01 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tom brings up a valid concern, and we fully plan on providing data and
tooling to make it easy to deploy the platform, composed of versions of
several releases known to work together, in a way that's easy to use and
easy to extend. Documenting which versions work together and/or deployed
to PWS together is easy, but we intend to provide an even better solution,
which is part of a broader effort to simplify manifest generation, and
using BOSH altogether.

Currently, this entails our CI producing a machine-readable artifact
encapsulating the versions of things known to work together, and a tool
that generates CF manifests using that artifact, but with the ability to
easily override things (e.g. choose to use a different version of a
stemcell). We have a prototype of this here:
https://github.com/cloudfoundry/cf-deployment, but we realized that we
needed to rebuild this in a test-driven fashion, and that effort is
underway here: https://github.com/cloudfoundry/mkman.

Mike has hit a lot of the key user-facing benefits on the head, I'll add
a couple more points that speak to benefits for contributors to CF itself:

- extracting things like a common route-registrar into the routing
release means that contributors to many other components (e.g. CC, UAA,
HM9k, Loggregator, service brokers) don't need to worry about any route
registration/nats logic, they can just colocate the route-registrar from
the lightweight routing release when they are deploying their stuff in a
context where registering a route makes sense. This is just one example.
- providing one release, with one set of job spec definitions, etc.
is much simpler to maintain than, e.g. uaa having to maintain one job spec
for the uaa within cf-release, one for the uaa within a bosh-release, and
one for the uaa as a standalone release.
- cf-release doesn't become a single bottleneck when failures occur
in the integration pipelines. Currently, all teams get blocked from
bumping their components to feed into the integration pipeline as soon as
one thing fails, because the cf-release repo is a single point of entry to
integration pipelines. Together with concourse, it's very easy to
integrate many releases, and simply "pause" one version of one release if
it breaks the build, allowing other components to continue to flow in.
- it is much easier to test the BOSH-operability of things when
they're in their own release. consul and etcd are great examples of this,
as they are generally difficult to orchestrate well in an automated
fashion, and testing things like scale-up, scale-down, rolling deploys, and
fault tolerance of our consul or etcd jobs if they are also part of a
massive cf-release and not their own thing, is more difficult.

Cheers,
Amit

On Fri, Feb 19, 2016 at 10:04 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

* In this case a release for each buildpack will reduce release
download sizes significantly. My org only uses Java and Node.
* Easily knowing what releases changed and which didn't will be nice.
(Not useful when everything is actively developed but more useful when
components grow more mature)
* If a bug is found in one release near an internal deploy deadline it
is easier to upgrade and test a single component with a fix instead than
waiting for the orchestration of an entirely new cf release with
potentially many more changes.
* Much easier to reuse releases outside of CF (e.g. UAA in bosh, etcd
or consul for internal projects)
* If using CF components like etcd, consul, or nats for in house CF
extensions it is easier for CF to sunset without forcing everyone who uses
it to migrate off. (On that note I'd like to see an independent Nats
release before it is removed from CF release)
* Easier to set up build environments if it ever becomes necessary to
do an internal fork of a release.

On the other hand it doesn't seem like documenting which combination of
components went into a given PWS deploy doesn't seem like that difficult of
a problem to solve. Also, as CF and its associated components mature I'd
imagine that tightly coupled release versions will become less of a problem.

Just a couple of thoughts.

Thanks,
Mike

On Fri, Feb 19, 2016 at 4:58 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

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 breaking them out?

Thanks,
Tom

On Thu, Feb 18, 2016 at 5:28 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is excellent! I love the decomposition of the buildpacks. I
look forward to the day when cf-release disappears and we just have a bunch
of small independent releases. Hopefully that day is getting closer and
closer.

Mike

On Thu, Feb 18, 2016 at 11:31 AM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Hey developers,

The buildpacks team has recently extracted the buildpacks as
separate releases. As we transition to deploying CF via a bunch of
composed releases, for now we're making the change more transparent, by
submoduling and symlinking the buildpacks releases back into cf-release.
This requires some manifest changes: buildpacks are now colocated with
cloud controller, rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding
the templates/jobs colocated on the api_zN jobs, you can ignore this
email. If you are overriding the api_zN templates in your stub, or if you
are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit