Re: [IMPORTANT] 2017 PaaS Certification Requirements

Daniel Jones

A short email turned into a long one.


- Make operator documentation part of certification
- Make release integration a concern of all vendors, and have them
contribute resources
- Make release integration's output a spec and not BOSH releases

Long version

David: Cheers for that explanation, I had taken a look at the repo and had
wondered what exactly the plan was.

Now, marketing and communications issues aside...

"instead start work on describing the BOSH <-> CF interface more cleanly,
and work to improve that so that various deployment mechanisms can be used"

This is an awesome idea.

If one is to bundle/package all the CF components together, then one needs
to understand:

- What versions of the components work together
- Which components depend on properties of others

Now that sounds pretty trivial, and it would be for a slow-moving project,
but for something as rapidly-changing as Cloud Foundry my impression is
that working this out anew on each version of cf-release would be quite an

If there was a machine-readable definition of these, then it would go a
long way to making it easier to deploy CF in different ways. However, the
thing I keep coming back to when pondering this is that the above is a
subset of a BOSH manifest. Then again, it's all the other BOSH cruft that
gets in the way of that being easily understood and parseable.

I'm going to explicitly show my ignorance here (rather than implicitly as I
usually do by way of blunder), and naively suggest a situation that may
already be what happens in some form.

CF Release Integration transitions from being a Pivotal team, to being a
cross-member team, with committed resource from each platinum partner
pushing their own distro. Their output is not a BOSH release but instead a
machine-readable spec of how compatible versions of components are plumbed
together. Distribution creators are then free to use this to generate their
own deployment methods. Members other than Pivotal are incentivised to
contribute staff to break the BOSH coupling, and Pivotal get the benefit of
being able to move resource elsewhere.

In an ideal universe where the Cloud Foundry Foundation has an army of
engineers, release integration could be a responsibility of the Foundation
as a neutral third party, as could acceptance tests. That'd then tie
together components that make up the platform, and executable tests, with
the organisation that determines what is certifiable.

Getting back to the BOSH/not-BOSH debate: how about if there was a
documentation element of certification? All certified distributions need to
meet certain criteria of easily-accessible documentation that explains how
to perform common tasks (equivalents of `bosh ssh`, scaling a component
out, and so on). That'd mean that operators need to know the types of
actions available to maintain a CF, and can be guaranteed easy access to
the implementation details thereof.

Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <>
*EngineerBetter* Ltd <> - UK Cloud Foundry

On Sat, Oct 29, 2016 at 2:51 AM, David Sabeti <dsabeti(a)> wrote:

I realize a big part of this thread is about BOSH, but I thought I could
provide a little more context about cf-deployment
<>, in case anyone is

cf-deployment will replace cf-release as the source of truth for how to
deploy Cloud Foundry. Instead of a repo with submodules of the various
components (cloud_controller_ng, gorouter, etc.), it's simply a BOSH
deployment manifest that references final release versions of the component
releases (capi-release, routing-release, etc.). Most importantly, it
includes diego-release and, by default, deploys Diego as the backend, in
the same deployment as CF.

The Release Integration team is already testing cf-deployment on a regular
basis and it passes acceptance-tests. We're currently working on fleshing
out the migration path from a spiff-template-generated manifest, which uses
the "v1 schema" for BOSH manifests, to cf-deployment, which uses the "v2
schema". (Note that "v1" and "v2" are not official versioning schemes for
BOSH, they're just a colloquial term that we sometimes use to describe a
collection of features which you read more about here
<>.) We're also planning to add
various forms of polish and configuration to cf-deployment.

As far as timelines go, our goal is to have cf-deployment generally
available for a few months before the EOL for the DEAs, to give everyone
time to do the migration. We're hoping to have it GA sometime in February.
We're already starting to dog-food it among the CF engineering teams to get
initial feedback. I'd encourage anybody who's interested in giving it a
shot to try and deploy with cf-deployment and to send feedback our way.

Feel free to reach out to me if you have any questions about cf-deployment.

David Sabeti
Product Manager, CF Release Integration

On Thu, Oct 27, 2016 at 7:12 AM Chip Childers <cchilders(a)>

I think the evolution from cf-release to cf-deployment is naturally
causing this to happen, although you make a very good point that perhaps
that could be accelerated and / or more explicit.

The DEA EOL notice that Dieu shared back in mid September talked about
the removal of the DEA's from cf-release after the 6 months of overlap
between Diego "1.0" and the DEA's being fully retired.

Lots of moving parts here, including needing to support the transition of
everyone from one to the other.

On Thu, Oct 27, 2016 at 4:47 AM Daniel Jones <
daniel.jones(a)> wrote:

Thanks for that Dieu!

Is there work scheduled to get OS cf-release and associated documentation
into a state where Diego is the default, rather than deploying the DEA

Daniel Jones - CTO
+44 (0)79 8000 9153 <+44%207980%20009153>
@DanielJonesEB <>
*EngineerBetter* Ltd <> - UK Cloud Foundry

On Thu, Oct 27, 2016 at 9:10 AM, Dieu Cao <dcao(a)> wrote:

Hello all,

The 2017 PaaS Certification Requirements is available here [1] and we
would appreciate questions/comments on the doc or in this thread.

I've also attached a PDF version for those of you that have difficulty
accessing google docs.

2 major changes from the 2016 certification requirements include
requiring Diego/Garden and also requiring the use of BOSH.

-Dieu Cao
Runtime PMC Lead


Chip Childers
VP Technology, Cloud Foundry Foundation <(267)%20250-0815>

Join { to automatically receive all group messages.