toggle quoted messageShow quoted text
Thanks a lot Amit for the heads up and the very interesting description of
the work on the "certified deployments".
I had once imagined to add in in the release meta-data the url to the ci
build that promoted the bosh dev release into a final release , cf .
This could be an initial first step indicating a certified deployment.
Having 1st class certified deployments (release version, stemcell,
bosh-director, and dependent releases) takes it to the next level.
On Tue, Aug 4, 2015 at 10:29 AM, Amit Gupta <agupta(a)pivotal.io> wrote:
cf-release notes do not specify a minimum version. They simply include a
soft recommendation, a known-good combination. They should not be regarded
as requirements, not something one would want a BOSH director to enforce.
I would not want to burn any particular soft recommendation into metadata
associated with a final release. A particular final release may be
compatible with many stemcells and releases, not all combinations of which
are known at final-release creation time. I'd rather have a discoverable,
queryable artifact published any time a particular (release version,
stemcell, director version, dependent-release versions) combination goes
green through the appropriate CI pipeline.
Let me expand on that last bit about publishing "green combinations".
Apologies in advance for taking the conversation in a different direction.
Nothing here precludes adding metadata to releases, but I think the big
picture problem you're trying to solve is not primarily to have releases
queryable and filterable, but some other abstraction be queryable and
A user is typically not interested in a particular release per se, but
rather a BOSH-deployed service or set of services, composed of one or more
BOSH deployments, each of which may be composed of one or more BOSH
releases, not to mention stemcells. Currently cf-release is the most
popular BOSH repository, it's typically used as a stand-alone release, as
part of a single deployment, and the manifest generation strategies are
encapsulated in the spiff templates that are checked into the release repo.
This model does not scale well, especially as it will become more and more
common for users to deploy the Diego backend for cloud foundry, whose
development has benefited greatly by being an independent release (and
usually, a separate deployment altogether, deployed alongside cf). Diego
is one of many examples* driving out a view that what the user consumes is
usually one, but sometimes several deployments, each composed of possibly
many releases, and sometimes even more than one stemcell. Note, part of
what the user consumes are the tools and templates to generate these
What the Release Integration team is working on over the next few months
is patterns for certifying deployments. A deployment is something like the
CF platform service, and what determines a good deployment is a combination
of all the things mentioned above (templates, releases, stemcells). I can
imagine these certified deployment artifacts becoming the thing one
searches, queries, and filters on bosh.io.
* other examples include:
- Concourse is typically deployed as a single deployment composed with
- Diego wants to consume garden-linux as a separate release to avoid
having the source code copy-pasted
- We want to extract etcd-release so that it's not copy pasted between cf
and diego, and can be used a general purpose etcd release
- We want to extract an identity release (UAA) so that cf and BOSH can
both re-use it without copy-paste
- Many services want to include a loggregator release so they can colocate
the metron agent on all of their jobs for metrics reporting, but don't want
to require the whole cf-release to get metron agent, thus the desire to
extract a loggregator-release
Amit, CF Release Integration PM
On Mon, Aug 3, 2015 at 11:52 PM, Guillaume Berche <bercheg(a)gmail.com>
Another use-case for such meta-data might be for a bosh release to
specify minimum bosh and stemcell supported versions (similar to what
cf-release release notes document informally, sometimes upon user requests
), and possibly have bosh director enforce these requirements.
On Sat, Jul 18, 2015 at 11:18 PM, Guillaume Berche <bercheg(a)gmail.com>
Great, thanks a lot Dmitriy, this sounds great.
Looking forward to seeing bosh.io leveraging these meta data to help
Le 18 juil. 2015 03:39, "Dmitriy Kalinin" <dkalinin(a)pivotal.io> a
I am thinking we can add metadata to config/final.yml (and eventually
include it in the release tarballs in release.MF). Once config/final.yml
includes metadata, bosh.io can pull it in down and include it on
release versions pages.
I'll reply to this thread with a format for config/final.yml based on
your repo in coming days.
Thanks for kicking this off!
On Fri, Jul 10, 2015 at 2:23 AM, Guillaume Berche <bercheg(a)gmail.com>
I'm wondering whether there are plans to add meta-data to bosh release
manifest, as to support better discoverability of bosh releases.
The bosh hub is providing a great one shop place to find bosh
releases, and it would be great to have it augmented with meta-data /
This meta-data could be external to the release (e.g. in bosh-hub) or
embedded in the release similar to juju charms meta-data  or most
package manager provide (yum, apt ...) to attach meta-data to packages.
I drafted possible meta-data / classification into  as to start the
Thanks in advance,
cf-bosh mailing list
cf-bosh mailing list