Re: [IMPORTANT] 2017 PaaS Certification Requirements
|
Daniel Jones
A short email turned into a long one.
toggle quoted message
Show quoted text
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 |
|
|