Date
1 - 20 of 40
[IMPORTANT] 2017 PaaS Certification Requirements
|
Dieu Cao <dcao@...>
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 |
|
|
|
Daniel Jones
Thanks for that Dieu!
toggle quoted message
Show quoted text
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 @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, |
|
|
|
Dr Nic Williams <drnicwilliams@...>
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?
toggle quoted message
Show quoted text
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 CaoRuntime PMC Lead [1]Â https://docs.google.com/document/d/1S9o4u65uG_YrVQAdg7nxw7BrXAiL64hFSWBNVKZCMNI/edit |
|
|
|
Dr Nic Williams <drnicwilliams@...>
"For managed offerings, BOSH does not need to be exposed to customers" - what is the origin & reason this is explicitly stated?
toggle quoted message
Show quoted text
Does it infer that there is any scenario at all where BOSH must be exposed to end users/customers? 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 CaoRuntime PMC Lead [1]Â https://docs.google.com/document/d/1S9o4u65uG_YrVQAdg7nxw7BrXAiL64hFSWBNVKZCMNI/edit |
|
|
|
Dr Nic Williams <drnicwilliams@...>
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?
toggle quoted message
Show quoted text
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 CaoRuntime PMC Lead [1]Â https://docs.google.com/document/d/1S9o4u65uG_YrVQAdg7nxw7BrXAiL64hFSWBNVKZCMNI/edit |
|
|
|
Chip Childers <cchilders@...>
Bundling up Dr. Nic's questions for a single reply... Great questions! I
toggle quoted message
Show quoted text
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 <cchilders@...>
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!Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815 |
|
|
|
Geoff Franks <geoff@...>
Is the BOSH requirement something that affects everyone, or just 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?
toggle quoted message
Show quoted text
On Oct 27, 2016, at 10:06 AM, Chip Childers <cchilders(a)cloudfoundry.org> wrote: |
|
|
|
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: Is the BOSH requirement something that affects everyone, or justChip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815 |
|
|
|
Chip Childers <cchilders@...>
To follow up... it was pointed out to me that the document didn't state
DRAFT well enough (it does now). My answers below were from the perspective of having thought this proposal through, and the context of what is and isn't a change from 2016. Any other comments from anyone? This is the time to say so if you have any.. including disagreements with any assumptions or thoughts below. Thanks all! 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-- Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815 |
|
|
|
Chip Childers <cchilders@...>
RE: Question #2 below -
toggle quoted message
Show quoted text
One of the things that we've been thinking about regarding operator experiences with Cloud Foundry, and why standardizing on BOSH may be very attractive, is figuring out how people that get skills in CF operations are able to move between different environments (service providers / product companies / enterprise users) and have relatively transferable skills across installations. This is something I'd like to test with feedback from the community. Does it seem valuable to have consistency for operators? Would there actually be consistency? 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 |
|
|
|
Daniel Jones
My tuppence/two cents:
I have met folks who used non-BOSH Cloud Foundry solutions, and were surprised when they hired people with "Cloud Foundry" on their resumes who then had to start from scratch when debugging operational issues. "I thought you operated Cloud Foundry in your last place?" "I did, but none of the tools work on *this* one." That's a marketing and reputation issue, right there. I'm all for more innovative (and resource-efficient) ways of deploying Cloud Foundry, and if BOSH isn't part of the deal then some thought needs to go into how these differences are communicated to users and customers such that they aren't left with any nasty surprises, because that's clearly bad for the ecosystem as a whole. 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 Thu, Oct 27, 2016 at 7:57 PM, Chip Childers <cchilders(a)cloudfoundry.org> wrote: RE: Question #2 below - |
|
|
|
Cornelius Schumacher
On Donnerstag, 27. Oktober 2016 01:10:37 CEST Dieu Cao wrote:
What does that mean for the stemcells? Is it required to use the stemcells being officially released by the BOSH team, or is this one of the "explicitly defined plugin points" where it's ok to use an alternative? -- Cornelius Schumacher <cschum(a)suse.de> |
|
|
|
Chip Childers <cchilders@...>
On Fri, Oct 28, 2016 at 3:10 AM Cornelius Schumacher <cschum(a)suse.de> wrote:
On Donnerstag, 27. Oktober 2016 01:10:37 CEST Dieu Cao wrote:What do you (or others) think would be the right approach?requiring -- Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815 |
|
|
|
Cornelius Schumacher
On Fri, 28. Oktober 2016 14:15:22 CEST Chip Childers wrote:
On Fri, Oct 28, 2016 at 3:10 AM Cornelius Schumacher <cschum(a)suse.de> wrote:I think it's good to keep some flexibility and openness, especially at suchOn Donnerstag, 27. Oktober 2016 01:10:37 CEST Dieu Cao wrote:What do you (or others) think would be the right approach?2 major changes from the 2016 certification requirements includerequiringDiego/Garden and also requiring the use of BOSH.What does that mean for the stemcells? Is it required to use the stemcells integration points as the stemcell where there are defined interfaces and tests. This can help to accommodate customers who have specific needs, e.g. because of standardization on certain infrastructure components. An all-in-one solution, while having its advantages, is just not always a viable option from an operational point of view, so having certain flexibility could increase adoption. I think it's also good from a community perspective as it results in a less monolithic project and allows for wider cooperation around components with well-defined integration points. It's easier to get involved and contribute if you can start with components and can keep some choices from where you are coming from. Requiring the use of BOSH already would be quite a strict requirement because there is overlap with other infrastructure and tools, which might already be in use. BOSH is a great way to deploy Cloud Foundry, but allowing for alternatives as well might have some benefits, e.g. around innovation as Dr. Nic already mentioned. So from my point of view it would be worth looking into ways how to keep some openness in the certification in these lower level areas which are not directly related to the user experience and maybe require interfaces or certain tests to be passed instead of specifying the exact implementation. -- Cornelius Schumacher <cschum(a)suse.de> |
|
|
|
Chip Childers <cchilders@...>
Great feedback Cornelius. Inline comments and questions for everyone below:
On Fri, Oct 28, 2016 at 12:55 PM Cornelius Schumacher <cschum(a)suse.de> wrote: On Fri, 28. Oktober 2016 14:15:22 CEST Chip Childers wrote:Your points are really good. I can also see a clear argument for eventuallyOn Fri, Oct 28, 2016 at 3:10 AM Cornelius Schumacher <cschum(a)suse.de>wrote:stemcellsOn Donnerstag, 27. Oktober 2016 01:10:37 CEST Dieu Cao wrote:2 major changes from the 2016 certification requirements includerequiringDiego/Garden and also requiring the use of BOSH.What does that mean for the stemcells? Is it required to use theI think it's good to keep some flexibility and openness, especially at suchbeing officially released by the BOSH team, or is this one of theWhat do you (or others) think would be the right approach? having multiple stemcells based on different Linux distros that CF can use (although it's more than just stemcells that would be needed). Another point of consideration is that stemcells can theoretically be re-baked with additional software for management / telemetry / etc... to fit into existing ITSM environments. The proposal didn't indicate any specific stemcells being required for these reasons. Requiring the use of BOSH already would be quite a strict requirementI'd like to hear more about this from the community. One side of the "argument" is the consistency that I was describing. I think there's significant value in more operational consistency across the CF ecosystem, for the reason that Daniel Jones went on to highlight else-thread. The other consistency argument relates to knowing that BOSH is there for packaging backend services (although it's also important that the Service Broker API continues to be implementation agnostic for lots of reasons). The other side is that experimentation / innovation around deployment and management of CF is valuable. We see non-BOSH deployment models in three of the existing "certified" offerings today. Does that benefit users / customers more than having consistency across offerings? Thoughts? So from my point of view it would be worth looking into ways how to keep-- Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815 |
|
|
|
Troy Topnik
It's important that this community understands that the *inclusion* of BOSH in the 2017 certification would *exclude* the Stackato and ContainerCF distributions which were certified in 2016, possibly others. This draft moves the goalposts significantly.
Quoting Chip: It's about consistency across the distributions. Requiring BOSH as theWhat about a consistent target for Cloud Foundry certified distributions? I completely disagree that this does not diminish experimentation. Companies will not invest in experiments that can never be commercially leveraged, and cannot make financial commitments without "consistency year over year" in the certification process itself. To provide a little of my perspective: HPE's Stackato team embarked on a huge effort to re-engineer our product to meet the 2016 Cloud Foundry certification standard. This involved deprecating a lot of code and starting basically from scratch to develop Stakato 4. We made this investment and took these risks with the understanding that the benefits of certification (customer confidence, compatibility, developers better positioned to contribute upstream, less churn maintaining forked code) would outweigh the hardships. If the BOSH requirement makes it into the 2017 certification we're actually worse off than we were a year ago, with less confidence that the requirements won't shift under our feet again. I'm not actually objecting to BOSH itself here, just the notion that adding it to Cloud Foundry certification requirements is necessary. BOSH was built to be a comprehensive release engineering tool for *any* project. Let it be it's own thing. TT -- Troy Topnik Sr. Product Manager | Helion Stackato troy.topnik(a)hpe.com |
|
|
|
Iovanov, Vlad Mircea
Regarding a consistent operator experience, I believe it will differ with or
toggle quoted message
Show quoted text
without BOSH being a requirement for certification. Some vendors will choose to add layers on top of BOSH, to improve UX, much like what Pivotal is doing with the Pivotal Operations Manager. So, in a sense, we can look at the common bits of CF as a kernel, from which you get distros. If I'm Red Hat certified, it doesn't mean I can transfer all my knowledge to Ubuntu. From an architectural perspective, I think it's a mistake to further couple BOSH with Cloud Foundry. During our CF containerization work, we've found that has already lead to bad coding practices. I am referring to ERB templates and tight coupling to monit. But BOSH does have great primitives. It prescribes how code needs to be organized, built and configured. That makes the codebase great for experimentation with other deployment mechanisms and strategies. For that reason, I think using the BOSH release as a form to package the certified code of Cloud Foundry is a good idea. But using BOSH to deploy Cloud Foundry would cut off the drive to experiment. Which means that no one will pay attention to the problems that come from tightly coupling the two systems. Furthermore, BOSH is a deployment mechanism for the VM world. Given the current investment of the industry towards containers, why are we trying to further tie Cloud Foundry to a VM-based infrastructure? On 10/28/16, 11:04 AM, "Topnik, Troy" <troy.topnik(a)hpe.com> wrote:
It's important that this community understands that the *inclusion* of BOSH in the 2017 certification would *exclude* the Stackato and ContainerCF distributions which were certified in 2016, possibly others. This draft moves the goalposts significantly. Quoting Chip: > 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. What about a consistent target for Cloud Foundry certified distributions? I completely disagree that this does not diminish experimentation. Companies will not invest in experiments that can never be commercially leveraged, and cannot make financial commitments without "consistency year over year" in the certification process itself. To provide a little of my perspective: HPE's Stackato team embarked on a huge effort to re-engineer our product to meet the 2016 Cloud Foundry certification standard. This involved deprecating a lot of code and starting basically from scratch to develop Stakato 4. We made this investment and took these risks with the understanding that the benefits of certification (customer confidence, compatibility, developers better positioned to contribute upstream, less churn maintaining forked code) would outweigh the hardships. If the BOSH requirement makes it into the 2017 certification we're actually worse off than we were a year ago, with less confidence that the requirements won't shift under our feet again. I'm not actually objecting to BOSH itself here, just the notion that adding it to Cloud Foundry certification requirements is necessary. BOSH was built to be a comprehensive release engineering tool for *any* project. Let it be it's own thing. TT -- Troy Topnik Sr. Product Manager | Helion Stackato troy.topnik(a)hpe.com |
|
|
|
Troy Topnik
I have met folks who used non-BOSH Cloud Foundry solutions, and wereI think this confusion (or misrepresentation) is best solved by the Cloud Foundry Expert Certification that Stormy Peters has coordinated. I objected initially to the mandatory inclusion of BOSH in that operator training and certification, but I'll concede that it does fix this potential problem for people hiring CF talent. TT |
|
|
|
Aaron L <aaron.lefkowitz@...>
*Long Answer: *I agree that BOSH can be better, as can all software ;-).The consistent target from an Engineering perspective should always be the contract or interface, but should never degrade to the point of being a particular implementation. This has been damaging in many open source projects. Where competition has always fostered excellence in these projects. Look at gcc and clang, or vim and neovim where the original projects were in states of decay, but a competitor emerging kicked them back into gear. Settling on BOSH as a lowest common denominator will make BOSH stagnate. With only one deployment mechanism and no clean interface to separate Cloud Foundry components and releases from BOSH implementation details, it's possible that the lines become so blurred that BOSH becomes impossible to remove. Even if at some point it becomes desirable because the community has reason to move away from BOSH (ie. rewrite time, or perhaps a better mechanism has been discovered or even leveraging a new open source project to do the same) it will be harder to do so, and hamper the evolution of the project. I'd propose keeping BOSH out of the CF certification, and instead start work on describing the BOSH <-> CF interface more cleanly, and work to improve that so that various deployment mechanisms can be used all the while retaining the consistency which seems to be the real goal we're trying to strive for here. |
|
|