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

Bundling up Dr. Nic's questions for a single reply... Great questions! I
did a bunch of the pre-work on behalf of the PMC Council on this topic, so
I have a bunch of the context loaded.

*Question #1:* To confirm - if a CF platform patches any CF components
outside of the biweekly or so release cycle that the components might have,
then they lose their certification status? I know some on-prem vendors
maintain private forks of cf-release and release patches of older versions
for their customers; is this allowed or not?

*Short Answer:* Yes

*Longer Answer:* "Offerings" should always be based on a specific
cf-release + recommended sub-components that aren't directly included in
the cf-release itself (really this will transition to cf-deployment once
that starts getting versioned "releases"). Bug fixes / vulnerability fixes
are allowed to be back-ported, based on the "Exceptions" listed. This
assumes that the fixes are in the upstream projects. Also notice the
section about "current versions". That's an important concept. In 2017, the
trademark license agreement that is used as the contractual vehicle for
certification will be a perpetual license to use the 2017 "certification
mark". The point here is that the upstream projects don't do LTS (long term
support), but vendors are allowed to. They just have to reference the
appropriate certification year for LTS versions.

*Question #2:* Why is "using BOSH" a requirement? As awesome as it is for
many things, it isn't perfect. If companies innovate/experiment with
alternate deployment systems why do they lose certification status?

*Short Answer:* Consistent operational experience and deployment platform
for services

*Long Answer: *I agree that BOSH can be better, as can all software ;-).
However, the certification process for offerings isn't about
experimentation in the ecosystem. It's about consistency across the
distributions. Requiring BOSH as the deployment method gives us two key
things: (1) much more consistency for operators of the platform and (2) a
consistent target (really a least common denominator) for ISV's packaging
software for backing services. The value of consistency year over year
doesn't diminish the value of experimentation outside of the certified
distributions.

*Question #3:* "For managed offerings, BOSH does not need to be exposed to
customers" - what is the origin & reason this is explicitly stated? Does it
infer that there is any scenario at all where BOSH must be exposed to end
users/customers?

*Short Answer:* It doesn't infer that for users.

*Long Answer:* That language was put in there to be specific that offerings
that are online PaaS services shouldn't be required to (and none do) expose
the BOSH layer to users of the Elastic Runtime layer (or customers
generally).

Hope that helps!

-chip


On Thu, Oct 27, 2016 at 5:29 AM Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

Also, why is "using BOSH" a requirement? As awesome as it is for many
things, it isn't perfect. If companies innovate/experiment with alternate
deployment systems why do they lose certification status?






On Thu, Oct 27, 2016 at 6:11 PM +1000, "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_YrVQAdg7nxw7BrXAiL64hFSWBNVKZCMNI/edit

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

--
Chip Childers
VP Technology, Cloud Foundry Foundation
1.267.250.0815