Re: [IMPORTANT] 2017 PaaS Certification Requirements
Chip Childers <cchilders@...>
It is a requirement for all certified offerings of all types. Regarding
why: see my comments about consistent operational experience (think about a
service provider's ops team as part of the market of people working with
the CF stack) and consistent deployment environment for Services.
On Thu, Oct 27, 2016 at 10:40 AM Geoff Franks <geoff(a)starkandwayne.com>
wrote:
VP Technology, Cloud Foundry Foundation
1.267.250.0815
why: see my comments about consistent operational experience (think about a
service provider's ops team as part of the market of people working with
the CF stack) and consistent deployment environment for Services.
On Thu, Oct 27, 2016 at 10:40 AM Geoff Franks <geoff(a)starkandwayne.com>
wrote:
Is the BOSH requirement something that affects everyone, or justChip Childers
non-managed offerings? If the only BOSH isn't required to be provided to
users from a managed-offering, why require it to have been present in
building what was offered? Shouldn't the part that matters for consistency
be the CF experience in those situations?
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>
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>
--
VP Technology, Cloud Foundry Foundation
1.267.250.0815