On 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 <mailto: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 <mailto: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 <https://docs.google.com/document/d/1S9o4u65uG_YrVQAdg7nxw7BrXAiL64hFSWBNVKZCMNI/edit>
--
Chip Childers
VP Technology, Cloud Foundry Foundation
1.267.250.0815 <tel:(267)%20250-0815>