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:

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:

2 major changes from the 2016 certification requirements include

requiring

Diego/Garden and also requiring the use of BOSH.

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?

What do you (or others) think would be the right approach?

I think it's good to keep some flexibility and openness, especially at such
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.

Your points are really good. I can also see a clear argument for eventually
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 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.

I'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
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
VP Technology, Cloud Foundry Foundation
1.267.250.0815