Hey Daniel,

Can you elaborate on the "BOSH cruft"? The plan is to have cf-deployment
and the releases which constitute it leverage BOSH links [0
<https://github.com/cloudfoundry/bosh-notes/blob/master/links.md>], global
networking [1
<https://github.com/cloudfoundry/bosh-notes/blob/master/finished/global-networking.md>],
config-server credential generation [2
<https://github.com/cloudfoundry/bosh-notes/blob/master/config-server.md>],
and cloud config [3
<https://github.com/cloudfoundry/bosh-notes/blob/master/finished/cloud-config.md>]
such that a lot of the cruft goes away. Imagine all credentials, IPs, and
things that should be defaults (e.g. nats.username: nats) gone from the
manifest.

I definitely think that theoretically, cleaner separations between CF and
BOSH would be beneficial indeed, and abstractly, the thing you're
describing (a spec of some sort) would be nice to have. The reality is
that (a) most operators of CF use BOSH, (b) *all *upstream teams need a
consistent way to deploy and test that their bits are likely to not break
things before promoting to the integration pipelines, and (c) the
integration pipelines need to be able to quickly build, deploy, and test
combinations of bits so that official releases can be cut when there's a
CVE fix coming from an upstream component. In an "army of engineers" world
it may be feasible to account for (a)-(c) while also developing an abstract
spec -- for now I'm skeptical and wouldn't change the team's mandate in my
personal opinion.

Also worth noting, an implicit requirement of the platform is
minimal-downtime upgrades. Release Integration's mandate should eventually
include building and running automated tests to certify such scenarios (and
each contributing team's mandate should include building solutions that can
work in such scenarios). This would be significantly more difficult
without being able to assume anything about the means of deployment and
orchestration.

By the way, CF Release Integration isn't a Pivotal team, it's a Foundation
team that happens to be staffed entirely by Pivotal employees. This isn't
unique to the Release Integration team. There have indeed been engineers
from other Foundation members contributing to Release Integration in the
past.

That said, I'm not necessarily arguing for (or against) the certification
requirement of BOSH-only. I want the experience of operators using BOSH to
deploy CF and anything else to improve significantly. Certification
requirements shouldn't hinder those efforts, but beyond that, I haven't
personally thought through the pros/cons of a BOSH-only requirement.

[0] https://github.com/cloudfoundry/bosh-notes/blob/master/links.md
[1]
https://github.com/cloudfoundry/bosh-notes/blob/master/finished/global-networking.md
[2] https://github.com/cloudfoundry/bosh-notes/blob/master/config-server.md
[3]
https://github.com/cloudfoundry/bosh-notes/blob/master/finished/cloud-config.md

Cheers,
Amit

On Sat, Oct 29, 2016 at 2:37 AM, Daniel Jones <
daniel.jones(a)engineerbetter.com> wrote:

A short email turned into a long one.

TL;DR:

- 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
overhead.

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.


Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists

On Sat, Oct 29, 2016 at 2:51 AM, David Sabeti <dsabeti(a)pivotal.io> 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
<https://github.com/cloudfoundry/cf-deployment>, in case anyone is
curious.

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
<https://github.com/cloudfoundry/bosh-notes>.) 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.

Best,
David Sabeti
Product Manager, CF Release Integration


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

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)engineerbetter.com> 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 architecture?

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153 <+44%207980%20009153>
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists

On Thu, Oct 27, 2016 at 9:10 AM, Dieu Cao <dcao(a)pivotal.io> 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

[1] https://docs.google.com/document/d/1S9o4u65uG_YrVQAdg7nx
w7BrXAiL64hFSWBNVKZCMNI/edit


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