The use case seems reasonable to me. Even if it's technically free (no marginal cost) to let processes consume the whole machine when it's available, I can easily see a commercial and technical case

Thanks all for the great feedback so far. I don't want to halt discussion, but it would be useful for everyone to get their opinions noted by EOD tomorrow (Tuesday). -- Chip Childers VP Technology,

+Will and Julz Thoughts gents? carlo.ferraris(a)rakuten.com> wrote: -- Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815

Sorry, I didn't explain that very well. Let me try again. In the simplest case where you're watch it from a terminal / console, yes it would be the same. A few cases where this might be an issue:

Hi Dan, How would that experience be different if trace went to stderr? Wouldn’t the stream of HTTP messages display inline with the cli output in the same way? Regards, Dies Koper Cloud Foundry

Hi Amit, Almost immediately after posting, it did dawn on me that BOSH '2.0' manifests do strip a lot of noise, so cf-deployment will go a long way towards this. A question for Dmitriy/Matt Reider

Hey Daniel, Can you elaborate on the "BOSH cruft"? The plan is to have cf-deployment and the releases which constitute it leverage BOSH links

A short email turned into a long one. TL;DR: - Make operator documentation part of certification - Make release integration a concern of all vendors, and have them contribute resources -

I realize a big part of this thread is about BOSH, but I thought I could provide a little more context about cf-deployment <https://github.com/cloudfoundry/cf-deployment>, in case anyone is

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

I 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

Regarding a consistent operator experience, I believe it will differ with or without BOSH being a requirement for certification. Some vendors will choose to add layers on top of BOSH, to improve UX,

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

Great feedback Cornelius. Inline comments and questions for everyone below: wrote: Your points are really good. I can also see a clear argument for eventually having multiple stemcells based on

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

See inline... Noted. It is an interesting point that this is isolated to just those circumstances. I don't think that this is a build pack error because you're not getting to the point where the

Hi Daniel, I tried starting the application with CF_TRACE enabled and/or checked the cc logs but did not find any thing useful yet in CF Trace only seeing generic error msg eg: 'Stager error:

What do you (or others) think would be the right approach? -- Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815

Great news! -- Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815

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