Dear all！

Do you have the solution to limit the qps of the app？

On Nov 13, 2015, at 2:51 PM, Deepak Vij (A) <deepak.vij(a)huawei.com> wrote:

If Mesosphere can do it for Kubernetes, CF/Diego is doable too. I am not worried about that, it is a solved problem.

The only concern I have is regarding deployment of Garden Container environment in Mesos/Slave/Executor. Although, this is not CF/Diego issues.

Because Mesos is not Garden Container environment aware, its underlying DRF scheduling algorithm may not have visibility to the resources being consumed within the Garden Container. Unless, we wrap Garden Container within the Docker container as Mesos supports Docker container environment. Although, this may not be right approach as it opens up another can of worms – Gardner Container nested within Docker Container. For Kubernetes environment this is not an issue as it uses Docker container to begin with.

- Deepak

From: resouer(a)163.com [mailto:resouer(a)163.com] On Behalf Of Zhang Lei
Sent: Thursday, November 12, 2015 8:24 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: Pluggable Resource Scheduling

You can add different scheduling strategy into Diego by implementing a scheduler plugin.


But not Mesos, that would be a huge task and another story.

The reason Kubernetes can integrate Mesos as scheduler (can work, not perfect) is due to Mesosphere is doing that part, I'm afraid ...

在 2015-11-13 03:57:52，"Deepak Vij (A)" <deepak.vij(a)huawei.com> 写道：

I did not mean to replace the whole “Diego” environment itself. What I was thinking was more in terms of plug-ability within Diego itself. This is so that “Auctioneer” component can be turned into a “Mesos Framework” as one of the scheduling options. By doing that, “Auctioneer” can start accepting “Mesos Offers” instead of native “Auctioning based Diego Resource Scheduling”. Rest of the runtime environment including Garden, Rep etc., they all stay the same. Nothing else changes. I hope this makes sense.

- Deepak

From: Gwenn Etourneau [mailto:getourneau(a)pivotal.io]
Sent: Wednesday, November 11, 2015 5:10 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Pluggable Resource Scheduling

Hi,

Interesting proposition, wondering if it make sense to hook into Diego or CF.
Diego is connected to CF by the CC-Bridge (big picture) why not create a CC-Bridge for other scheduling system ?



Thanks

On Thu, Nov 12, 2015 at 5:13 AM, Deepak Vij (A) <deepak.vij(a)huawei.com> wrote:
Hi folks, I would like to start a discussion thread and get community thoughts regarding availability of Pluggable Resource Scheduling within CF/Diego. Just like Kubernetes does, wouldn’t it be nice to have an option of choosing Diego native scheduling or other uber/global resource management environments, specifically Mesos.

Look forward to comments and feedback from the community. Thanks.

Regards,
Deepak Vij
(Huawei Software Lab., Santa Clara)

Hi,

I'm not sure what strategies exist either. This same topic came up
partially in the context of my resubmitted FIPS proposal, and I was curious
- is it worth creating an issue (or even a separate feature
proposal/blueprint) for tooling to rotate encryption keys? It's nontrivial
(unless there is tooling about which I am unaware) to do, and a good
solution in this space would IMHO fill a significant operational need.

Thoughts?

-Sandy


--
Sandy Cash
Certified Senior IT Architect/Senior SW Engineer
IBM BlueMix
lhcash(a)us.ibm.com
(919) 543-0209

"I skate to where the puck is going to be, not to where it has been.” -
Wayne Gretzky

[image: Inactive hide details for Dieu Cao ---11/12/2015 02:19:53 PM---Hi
William, Thanks for the links.]Dieu Cao ---11/12/2015 02:19:53 PM---Hi
William, Thanks for the links.

From: Dieu Cao <dcao(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Date: 11/12/2015 02:19 PM
Subject: [cf-dev] Re: Re: Re: Cloud Controller - s3 encryption for
droplets
------------------------------



Hi William,

Thanks for the links.
We don't have support for client side encryption currently.
Cloud Controller and Diego's blobstore clients would need to be modified
to encrypt and decrypt for client side encryption and I'm not clear what
strategies exist for rotation of keys in these scenarios.

If you're very interested in this feature and are open to working through
requirements with me and submitting a PR, please open up an issue on github
and we can discuss this further.

-Dieu

On Tue, Nov 10, 2015 at 4:16 PM, William C Penrod <*wcpenrod(a)gmail.com*
<wcpenrod(a)gmail.com>> wrote:

I first ran across it here:

*http://cloudfoundryjp.github.io/docs/running/bosh/components/blobstore.html*
<http://cloudfoundryjp.github.io/docs/running/bosh/components/blobstore.html>

and checked here for additional info:

*https://github.com/cloudfoundry/bosh/blob/master/blobstore_client/lib/blobstore_client/s3_blobstore_client.rb*
<https://github.com/cloudfoundry/bosh/blob/master/blobstore_client/lib/blobstore_client/s3_blobstore_client.rb>

Hi Felix,

You are right, we have found this issue in one of our own environments as
well, we have a story here
<https://www.pivotaltracker.com/story/show/105340048> to address it by
skipping verification explicitly for this test only. Previously, I
believe
that test only used an http URL when curling, recent updates to allow
configuration of the protocol exposed this issue. We do not assume
multi-level wildcard certs.

The curl helper was also changed recently to set SSL verification
internally
for all curl commands
<https://github.com/cloudfoundry/cf-acceptance-tests/commit/06c83fa5641785ebca1c6dedb36c2370415e3005>,
so the skip_ssl_validation configuration should still be working
correctly.

If you want to see the tests pass, you could either set
"skip_ssl_validation" to false or "use_http" to true and the test should
work as intended. In any case, we are sorry for the failures and
hopefully
we can get a fix out soon.

- Chris

On Mon, Oct 19, 2015 at 7:32 AM, Felix Friedrich <felix(a)fri.edri.ch>
wrote:

Hello,

we've just upgraded our CF deployment from v215 to v220. Unfortunately
the acceptance tests fail: http://pastebin.com/rWrXX1HA
They reasonably fail. The test expects a valid ssl cert, but our cert is
only valid for *.test.cf.springer-sbm.com not for
*.*.test.cf.springer-sbm.com. The test seem to expect a multilevel SSL
cert, I am not sure if that's reasonable or not.

However, I wondered why this exact test did not fail in v215. I
suspected that the way curl gets executed in the v220 tests changed and
it apparently seems that I am right [1]. Thus I assume (!) that before
curl's return codes did not get propagated, while they are now. (Return
code 51 is "The peer's SSL certificate or SSH MD5 fingerprint was not
OK." according to the man page.)

Also the new way of executing ("curlCmd := runner.Curl(uri)") does not
look like it gets the skipSslValidation value. As a fact running the
acceptances tests with the skip_ssl_validation option still leads to
this test failing. However the used library looks like it is able to
skip SSL validation:

https://github.com/cloudfoundry-incubator/cf-test-helpers/blob/master/runner/run.go

Even if skip_ssl_validation would work, I am not very keen on activating
that option since that also applies to all other tests, which are not
using multi level wildcard certs.

Besides of the fact that curl seems to validate SSL certs no matter if
skip_ssl_validation is true or false, did you intentionally assume that
CF uses a multilevel wildcard cert?


Felix



[1]

https://github.com/cloudfoundry/cf-acceptance-tests/compare/353e06565a6a1a0d6b4c417f57b00eeecec604fa...72496c6fabd1c8ec51ae932d13a597a62ccf30dd

Jack,

This is correct.

The online version and the offline version of the buildpack only differ
one way. The offline version has the dependencies, defined in the
`manifest.yml`, packaged with it.

They both keep the same contract that we'll only support certain versions
of runtimes (Ruby, Python, etc).


-- JT

On Thu, Nov 12, 2015 at 2:46 PM, Jack Cai <greensight(a)gmail.com> wrote:

Thanks Mike. Is it true that even for the online version (aka when doing
"cf push -b https://github.com/cloudfoundry/nodejs-buildpack.git"),
users are now limited to use the runtime versions defined in the
manifest.yml?

Jack


On Thu, Nov 12, 2015 at 12:05 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

This is a bug in the nodejs-buildpack v1.5.1, which we should have a fix
for later today.

Github issue is here:
https://github.com/cloudfoundry/nodejs-buildpack/issues/35

Tracker story is here:
https://www.pivotaltracker.com/story/show/107946000

Apologies for the inconvenience.

On Thu, Nov 12, 2015 at 12:03 PM, Jack Cai <greensight(a)gmail.com> wrote:

For the cached package of the buildpacks, I thought it would refuse to
provide a runtime version that's not cached. Yesterday I was playing with
the node.js buildpack and found it actually will download a non-cached
node.js runtime. Does it mean we kind of moved to the "hybrid" model I
suggested earlier in this thread? Does it work the same way for
java/go/php/ruby/python buildpacks as well?

Jack




On Mon, Apr 13, 2015 at 3:08 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi Jack,

Thanks so much for your feedback!

Based on my conversations with CF users to date, this is definitely
something that we would want to be "opt-in" behavior; the consensus-desired
default appears to be to disallow the downloading of old/deprecated
versions.

Notably, though, what we'll continue to support is the specification
of a buildpack using the `cf push` `-b` option:

```
-b Custom buildpack by name (e.g. my-buildpack) or GIT URL
```

Buildpacks used in this manner will behave in "online" mode, meaning
they'll attempt to download dependencies from the public internet. Does
that satisfy your needs, at least in the short-term?

-m


On Mon, Apr 13, 2015 at 1:59 PM, Jack Cai <greensight(a)gmail.com>
wrote:

We will no longer provide "online" buildpack releases, which

download dependencies from the public internet.

I think it would make sense to retain the ability to download
additional runtime versions on demand (that's not packaged in the
buildpack) if the user explicitly requests it. So basically it will be a
hybrid model, where the most recent versions are "cached", while old
versions are still available.

Jack


On Wed, Apr 8, 2015 at 11:36 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Hey Patrick,

Sorry about that - the diego-dev-notes is an internal documentation
repo that the Diego team uses to stay on the same page and toss ideas
around.

There isn't much that's terribly interesting at that link - just
some ideas on how to extend diego's existing caching capabilities to avoid
copying cached artifacts into containers (we'd mount them in
directly instead).

Happy to share more detail if there is interest.

Onsi

On Wednesday, April 8, 2015, Patrick Mueller <pmuellr(a)gmail.com>
wrote:

I got a 404 on
https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/better-buildpack-caching.md

On Wed, Apr 8, 2015 at 11:10 AM, Mike Dalessio <
mdalessio(a)pivotal.io> wrote:

Hello vcap-dev!

This email details a proposed change to how Cloud Foundry
buildpacks are packaged, with respect to the ever-increasing number of
binary dependencies being cached within them.

This proposal's permanent residence is here:


https://github.com/cloudfoundry-incubator/buildpack-packager/issues/4

Feel free to comment there or reply to this email.
------------------------------
Buildpack SizesWhere we are today

Many of you have seen, and possibly been challenged by, the
enormous sizes of some of the buildpacks that are currently shipping with
cf-release.

Here's the state of the world right now, as of v205:

php-buildpack: 1.1G
ruby-buildpack: 922M
go-buildpack: 675M
python-buildpack: 654M
nodejs-buildpack: 403M
----------------------
total: 3.7G

These enormous sizes are the result of the current policy of
packaging every-version-of-everything-ever-supported ("EVOEES") within the
buildpack.

Most recently, this problem was exacerbated by the fact that
buildpacks now contain binaries for two rootfses.
Why this is a problem

If continued, buildpacks will only continue to increase in size,
leading to longer and longer build and deploy times, longer test times,
slacker feedback loops, and therefore less frequent buildpack releases.

Additionally, this also means that we're shipping versions of
interpreters, web servers, and libraries that are deprecated, insecure, or
both. Feedback from CF users has made it clear that many companies view
this as an unnecessary security risk.

This policy is clearly unsustainable.
What we can do about it

There are many things being discussed to ameliorate the impact
that buildpack size is having on the operations of CF.

Notably, Onsi has proposed a change to buildpack caching, to
improve Diego staging times (link to proposal
<https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/better-buildpack-caching.md>
).

However, there is an immediate solution available, which addresses
both the size concerns as well as the security concern: packaging fewer
binary dependencies within the buildpack.
The proposal

I'm proposing that we reduce the binary dependencies in each
buildpack in a very specific way.

Aside on terms I'll use below:

- Versions of the form "1.2.3" are broken down as:
MAJOR.MINOR.TEENY. Many language ecosystems refer to the "TEENY" as "PATCH"
interchangeably, but we're going to use "TEENY" in this proposal.
- We'll assume that TEENY gets bumped for API/ABI compatible
changes.
- We'll assume that MINOR and MAJOR get bumped when there are
API/ABI *incompatible* changes.

I'd like to move forward soon with the following changes:

1. For language interpreters/compilers, we'll package the two
most-recent TEENY versions on each MAJOR.MINOR release.
2. For all other dependencies, we'll package only the single
most-recent TEENY version on each MAJOR.MINOR release.
3. We will discontinue packaging versions of dependencies that
have been deprecated.
4. We will no longer provide "EVOEES" buildpack releases.
5. We will no longer provide "online" buildpack releases,
which download dependencies from the public internet.
6. We will document the process, and provide tooling, for CF
operators to build their own buildpacks, choosing the dependencies that
their organization wants to support or creating "online" buildpacks at
operators' discretion.

An example for #1 is that we'll go from packaging 34 versions of
node v0.10.x to only packaging two: 0.10.37 and 0.10.38.

An example for #2 is that we'll go from packaging 3 versions of
nginx 1.5 in the PHP buildpack to only packaging one: 1.5.12.

An example for #3 is that we'll discontinue packaging ruby 1.9.3
in the ruby-buildpack, which reached end-of-life in February 2015.
Outcomes

With these changes, the total buildpack size will be reduced
greatly. As an example, we expect the ruby-buildpack size to go from 922M
to 338M.

We also want to set the expectation that, as new interpreter
versions are released, either for new features or (more urgently) for
security fixes, we'll release new buildpacks much more quickly than we do
today. My hope is that we'll be able to do it within 24 hours of a new
release.
Planning

These changes will be relatively easy to make, since all the
buildpacks are now using a manifest.yml file to declare what's
being packaged. We expect to be able to complete this work within the next
two weeks.

Stories are in the Tracker backlog under the Epic named
"skinny-buildpacks", which you can see here:

https://www.pivotaltracker.com/epic/show/1747328

------------------------------

Please let me know how these changes will impact you and your
organizations, and let me know of any counter-proposals or variations you'd
like to consider.

Thanks,

-mike


--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZwDbON2B6cAynyJY12tCWXO8XPKSCmhCc%3D%3DBu4KsHe%3DhA%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZwDbON2B6cAynyJY12tCWXO8XPKSCmhCc%3D%3DBu4KsHe%3DhA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it,
send an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
Patrick Mueller
http://muellerware.org

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CACAoQH0-dCrN6o%2B%3Ds1kn3poJSusUWbV6Zzsk29FTRs_kQfYtaQ%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CACAoQH0-dCrN6o%2B%3Ds1kn3poJSusUWbV6Zzsk29FTRs_kQfYtaQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it,
send an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-x8JD36rQFCHOnuDpOojYpVFZ_xBH1JzoTHWaEKC5Vqog%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-x8JD36rQFCHOnuDpOojYpVFZ_xBH1JzoTHWaEKC5Vqog%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it,
send an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CANbAaBTNMr9QwyopJJJ6VpZWz%2BGYr-Q_xL0UsnX2ha6OzkAcag%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CANbAaBTNMr9QwyopJJJ6VpZWz%2BGYr-Q_xL0UsnX2ha6OzkAcag%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it,
send an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZyo9VszAcgQRCuAfQ3r%3Di2PksDq2Hkv6N-kObs053hOFg%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZyo9VszAcgQRCuAfQ3r%3Di2PksDq2Hkv6N-kObs053hOFg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it, send
an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

Thanks Mike. Is it true that even for the online version (aka when doing
"cf push -b https://github.com/cloudfoundry/nodejs-buildpack.git"), users
are now limited to use the runtime versions defined in the manifest.yml?

Jack


On Thu, Nov 12, 2015 at 12:05 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

This is a bug in the nodejs-buildpack v1.5.1, which we should have a fix
for later today.

Github issue is here:
https://github.com/cloudfoundry/nodejs-buildpack/issues/35

Tracker story is here:
https://www.pivotaltracker.com/story/show/107946000

Apologies for the inconvenience.

On Thu, Nov 12, 2015 at 12:03 PM, Jack Cai <greensight(a)gmail.com> wrote:

For the cached package of the buildpacks, I thought it would refuse to
provide a runtime version that's not cached. Yesterday I was playing with
the node.js buildpack and found it actually will download a non-cached
node.js runtime. Does it mean we kind of moved to the "hybrid" model I
suggested earlier in this thread? Does it work the same way for
java/go/php/ruby/python buildpacks as well?

Jack




On Mon, Apr 13, 2015 at 3:08 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi Jack,

Thanks so much for your feedback!

Based on my conversations with CF users to date, this is definitely
something that we would want to be "opt-in" behavior; the consensus-desired
default appears to be to disallow the downloading of old/deprecated
versions.

Notably, though, what we'll continue to support is the specification of
a buildpack using the `cf push` `-b` option:

```
-b Custom buildpack by name (e.g. my-buildpack) or GIT URL
```

Buildpacks used in this manner will behave in "online" mode, meaning
they'll attempt to download dependencies from the public internet. Does
that satisfy your needs, at least in the short-term?

-m


On Mon, Apr 13, 2015 at 1:59 PM, Jack Cai <greensight(a)gmail.com> wrote:

We will no longer provide "online" buildpack releases, which

download dependencies from the public internet.

I think it would make sense to retain the ability to download
additional runtime versions on demand (that's not packaged in the
buildpack) if the user explicitly requests it. So basically it will be a
hybrid model, where the most recent versions are "cached", while old
versions are still available.

Jack


On Wed, Apr 8, 2015 at 11:36 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Hey Patrick,

Sorry about that - the diego-dev-notes is an internal documentation
repo that the Diego team uses to stay on the same page and toss ideas
around.

There isn't much that's terribly interesting at that link - just some
ideas on how to extend diego's existing caching capabilities to avoid
copying cached artifacts into containers (we'd mount them in
directly instead).

Happy to share more detail if there is interest.

Onsi

On Wednesday, April 8, 2015, Patrick Mueller <pmuellr(a)gmail.com>
wrote:

I got a 404 on
https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/better-buildpack-caching.md

On Wed, Apr 8, 2015 at 11:10 AM, Mike Dalessio <mdalessio(a)pivotal.io

wrote:

Hello vcap-dev!

This email details a proposed change to how Cloud Foundry
buildpacks are packaged, with respect to the ever-increasing number of
binary dependencies being cached within them.

This proposal's permanent residence is here:


https://github.com/cloudfoundry-incubator/buildpack-packager/issues/4

Feel free to comment there or reply to this email.
------------------------------
Buildpack SizesWhere we are today

Many of you have seen, and possibly been challenged by, the
enormous sizes of some of the buildpacks that are currently shipping with
cf-release.

Here's the state of the world right now, as of v205:

php-buildpack: 1.1G
ruby-buildpack: 922M
go-buildpack: 675M
python-buildpack: 654M
nodejs-buildpack: 403M
----------------------
total: 3.7G

These enormous sizes are the result of the current policy of
packaging every-version-of-everything-ever-supported ("EVOEES") within the
buildpack.

Most recently, this problem was exacerbated by the fact that
buildpacks now contain binaries for two rootfses.
Why this is a problem

If continued, buildpacks will only continue to increase in size,
leading to longer and longer build and deploy times, longer test times,
slacker feedback loops, and therefore less frequent buildpack releases.

Additionally, this also means that we're shipping versions of
interpreters, web servers, and libraries that are deprecated, insecure, or
both. Feedback from CF users has made it clear that many companies view
this as an unnecessary security risk.

This policy is clearly unsustainable.
What we can do about it

There are many things being discussed to ameliorate the impact that
buildpack size is having on the operations of CF.

Notably, Onsi has proposed a change to buildpack caching, to
improve Diego staging times (link to proposal
<https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/better-buildpack-caching.md>
).

However, there is an immediate solution available, which addresses
both the size concerns as well as the security concern: packaging fewer
binary dependencies within the buildpack.
The proposal

I'm proposing that we reduce the binary dependencies in each
buildpack in a very specific way.

Aside on terms I'll use below:

- Versions of the form "1.2.3" are broken down as:
MAJOR.MINOR.TEENY. Many language ecosystems refer to the "TEENY" as "PATCH"
interchangeably, but we're going to use "TEENY" in this proposal.
- We'll assume that TEENY gets bumped for API/ABI compatible
changes.
- We'll assume that MINOR and MAJOR get bumped when there are
API/ABI *incompatible* changes.

I'd like to move forward soon with the following changes:

1. For language interpreters/compilers, we'll package the two
most-recent TEENY versions on each MAJOR.MINOR release.
2. For all other dependencies, we'll package only the single
most-recent TEENY version on each MAJOR.MINOR release.
3. We will discontinue packaging versions of dependencies that
have been deprecated.
4. We will no longer provide "EVOEES" buildpack releases.
5. We will no longer provide "online" buildpack releases, which
download dependencies from the public internet.
6. We will document the process, and provide tooling, for CF
operators to build their own buildpacks, choosing the dependencies that
their organization wants to support or creating "online" buildpacks at
operators' discretion.

An example for #1 is that we'll go from packaging 34 versions of
node v0.10.x to only packaging two: 0.10.37 and 0.10.38.

An example for #2 is that we'll go from packaging 3 versions of
nginx 1.5 in the PHP buildpack to only packaging one: 1.5.12.

An example for #3 is that we'll discontinue packaging ruby 1.9.3 in
the ruby-buildpack, which reached end-of-life in February 2015.
Outcomes

With these changes, the total buildpack size will be reduced
greatly. As an example, we expect the ruby-buildpack size to go from 922M
to 338M.

We also want to set the expectation that, as new interpreter
versions are released, either for new features or (more urgently) for
security fixes, we'll release new buildpacks much more quickly than we do
today. My hope is that we'll be able to do it within 24 hours of a new
release.
Planning

These changes will be relatively easy to make, since all the
buildpacks are now using a manifest.yml file to declare what's
being packaged. We expect to be able to complete this work within the next
two weeks.

Stories are in the Tracker backlog under the Epic named
"skinny-buildpacks", which you can see here:

https://www.pivotaltracker.com/epic/show/1747328

------------------------------

Please let me know how these changes will impact you and your
organizations, and let me know of any counter-proposals or variations you'd
like to consider.

Thanks,

-mike


--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZwDbON2B6cAynyJY12tCWXO8XPKSCmhCc%3D%3DBu4KsHe%3DhA%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZwDbON2B6cAynyJY12tCWXO8XPKSCmhCc%3D%3DBu4KsHe%3DhA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it,
send an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
Patrick Mueller
http://muellerware.org

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CACAoQH0-dCrN6o%2B%3Ds1kn3poJSusUWbV6Zzsk29FTRs_kQfYtaQ%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CACAoQH0-dCrN6o%2B%3Ds1kn3poJSusUWbV6Zzsk29FTRs_kQfYtaQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it,
send an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-x8JD36rQFCHOnuDpOojYpVFZ_xBH1JzoTHWaEKC5Vqog%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-x8JD36rQFCHOnuDpOojYpVFZ_xBH1JzoTHWaEKC5Vqog%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it,
send an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CANbAaBTNMr9QwyopJJJ6VpZWz%2BGYr-Q_xL0UsnX2ha6OzkAcag%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CANbAaBTNMr9QwyopJJJ6VpZWz%2BGYr-Q_xL0UsnX2ha6OzkAcag%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it, send
an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZyo9VszAcgQRCuAfQ3r%3Di2PksDq2Hkv6N-kObs053hOFg%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGeQLZyo9VszAcgQRCuAfQ3r%3Di2PksDq2Hkv6N-kObs053hOFg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it, send
an email to vcap-dev+unsubscribe(a)cloudfoundry.org.