|
UAA with external openid connect
We are looking at revamping the UAA integrations we are using for our
deployments.
Our enterprise authentication provider supports SAML and OpenID Connect for
single signon. I know that UAA supports SAML. Is it possible to use our
enterprise OpenID Connect provider to authenticate for UAA OAuth? Or
should I just use SAML?
Mike
|
|
|
Project Lead Change for Diego and Garden Incubating Projects
Chip Childers <cchilders@...>
Onsi Fakhouri has resigned from the runtime PMC's Diego and Garden
incubating projects, given his new $dayjob responsibilities at Pivotal.
Eric Malm will be stepping in to take his place for the Diego project.
Will Pragnell will be stepping in to take his place for the Garden project.
Thanks!
-chip
Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation
|
|
|
Which components can be HA?
Hi Is http://docs.cloudfoundry.org/concepts/high-availability.html up to date? 1) Why is collector listed 1 but in scalable process table? 2) How do you run a second Health Manager in standby mode if only 1 can run at any time? 3) Do we still need clock job? Is it also 1 instance? 4) I notice I have a job called api_workers, and I believe that's compilation machine. I run two of these 24x7, is that necessary? The doc said it is active if we need to compile things (say deploying a new release). Is that all? I don't think they handle application code compilation. 5) What about syslog? Can it have 2? I understand we have to choose what to be HA or not...I am not sure "the BOSH resurrector will recover the VM if it becomes non-responsive" convinces me because all of these jobs are deployed with BOSH but if BOSH is down I am facing some outage. I know Dr. Nic has some article regarding HA bosh. Correct me if I am wrong. Thanks. John
|
|
|
Purge files on NFS or S3?
Hi
I just looked at our disk usage on NFS server. We have used like 200G so
far, and I wonder if there's a systematic way to purge files we don't need
(or how do I know I don't need them)?
Similarly, if I were to replace NFS server with S3 instead, does the
existing process (if any) work with S3?
Thanks.
|
|
|
HP Incubator Proposals for Microsoft "Stack" Support
Chip Childers <cchilders@...>
All, HP is proposing a sizable donation of code into the Cloud Foundry Foundation's incubation program. This represents a collection of projects that together provide support for a full stack of Microsoft technologies for Cloud Foundry. This includes a Visual Studio Extension, MS Buildpack, .NET SDK for the Cloud Controller API, Windows-based DEAs and a SQL Server service broker implementation. Gert Drapers (from HP) and I have been working with Mark Kropf, Mike Dalessio and several members of the Greenhouse incubating project to plan out how we can accept this into the incubator, as well as working with HP on a plan to onboard their engineering team via the Dojo program. I've grouped each repository that is being proposed for donation into the applicable PMC and noted what project (existing or new) would manage the code. Comments are welcome, and we will be working with each PMC directly to ensure consensus. *Runtime PMC* These two repositories would land in the existing Greenhouse incubating project, and HP engineers will join that project via the Dojo program. While this implementation is an alternative to the approach that is currently being taken by the Greenhouse project, it is implemented for the DEA architecture (vs. Diego). The work of the expanded Greenhouse project will be to rationalize the multiple approaches and determine what the combined architectural path will be for the future. Windows Prison (isolation code) https://github.com/hpcloud/cf-windows-prisonWindows Extensions (WinDEA for CFv2) https://github.com/hpcloud/cf-windows-extensionsAdditionally, there are two build packs being donated, which will (for now) incubate within the runtime PMC’s Greenhouse project. The goal would be to move these to the Buildpacks PMC at the same time that the Greenhouse work moves from incubating to active. Core build pack used by the DEA (Windows Extensions) https://github.com/hpcloud/hp-buildpack-iis8, we should rename this to cf-iis8-buildback or cf-buildpack-iis8 Static Windows executable build pack https://github.com/hpcloud/cf-exe-buildpack*Services PMC* The SQL Server service broker proposed below would be a new incubating project for the Services PMC. HP engineers would be the initial committers for this project within the Services PMC. We will work to identify the appropriate project lead for the new incubating project. Microsoft SQL Server Service Broker (v2 broker written in go) https://github.com/hpcloud/cf-mssql-broker*Utilities PMC* The .NET SDK and and Visual Studio Extension / MSBuild Tasks projects would be two new incubating projects within the Utilities PMC, similar to how we have the Java Tools and Eclipse Plugin projects today. HP engineers would be the initial committers for these projects within the Utilities PMC. We will work to identify the appropriate project lead for the new incubating projects. CF .NET SDK https://github.com/hpcloud/cf-dotnet-sdkCF Visual Studio Extension https://github.com/hpcloud/cf-vs-extension-wpf will be renamed to https://github.com/hpcloud/cf-vs-extensionCF MSBuild Tasks https://github.com/hpcloud/cf-msbuild-tasks-chip Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation
|
|
|
Re: [vcap-dev] Proposal to bring Service Broker for Apache Brooklyn and CLI-Plugin into Incubator
Chip Childers <cchilders@...>
The proposal will be reviewed on Thursday by the Services PMC. Thanks Duncan! Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation On Mon, May 4, 2015 at 8:42 PM, Duncan Johnston Watt < duncan.johnstonwatt(a)cloudsoftcorp.com> wrote: Chip/All
Just following up on this proposal on the new list to get an update on its
status.
Best
Duncan
On 22 April 2015 at 14:49, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:
General feedback is desired here from the whole community, so speak up!
After that feedback, we will work within the Services PMC to accept (or
deny) this code contribution into the incubator for that PMC.
Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation
On Wed, Apr 22, 2015 at 6:22 AM, Robert Moss <
robert.moss(a)cloudsoftcorp.com> wrote:
Hi All,
I've put together a proposal[1] to bring the Service Broker for Apache
Brooklyn and CLI-Plugin into the Incubator. If you haven't yet seen, I
wrote a series of blog posts with videos[2][3][4] describing them. Looking
forward to your feedback.
Robert
[1]
https://docs.google.com/a/cloudsoftcorp.com/document/d/15HuoflKjf5dbrbuTHGVE7kyniIBADUh24MmYBXU-CYw/edit#heading=h.qnq5iz827eiu
[2]
http://www.cloudsoftcorp.com/blog/2015/02/integrating-cloud-foundry-apache-brooklyn-part-1-service-broker/
[3]
http://www.cloudsoftcorp.com/blog/2015/02/integrating-cloud-foundry-apache-brooklyn-part-2-brooklyn-plugin/
[4]
http://www.cloudsoftcorp.com/blog/2015/04/integrating-cloud-foundry-with-apache-brooklyn-part-3-managing-services/
--
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/318d03e2-581c-4cf1-93b5-1178defe38d7%40cloudfoundry.org
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/318d03e2-581c-4cf1-93b5-1178defe38d7%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.
--
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/CAD1Pwce9cTJtevYhozkzYen%3DmqF0rz0Xnq9OHG%2Bhv5AvcS%3DdHQ%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAD1Pwce9cTJtevYhozkzYen%3DmqF0rz0Xnq9OHG%2Bhv5AvcS%3DdHQ%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.
--
Duncan Johnston-Watt
CEO | Cloudsoft Corporation
Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.com/in/duncanjohnstonwatt
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Addressing buildpack size
I'm happy to see the size of the build packs dropping, but I have to ask why do we bundle the build packs with a fixed set of binaries? The build packs themselves are very small, it's the binaries that are huge. It seems like it would make sense to handle them as separate concerns. I don't want to come off too harsh, but in addition to the size of the build packs when bundled with binaries, there are some other disadvantages to doing things this way. - Binaries and build packs are updated at different rates. Binaries are usually updated often, to pick up new runtimes versions & security fixes; build packs are generally changed at a slower pace, as features or bug fixes for them are needed. Bundling the two together, requires an operator to update the build packs more often, just to get updated binaries. It's been my experience that users don't (or forget) to update build packs which means they're likely running with older, possibly insecure runtimes. - It's difficult to bundle a set of runtime binaries that suite everyone's needs, different users will update at different rates and will want different sets of binaries. If build packs and binaries are packaged together, users will end up needing to find a specific build pack bundle that contains the runtime they want or users will need to build their own custom bundles. If build packs and binaries are handled separately, there will be more flexibility in what binaries a build pack has available as an operator can manage binaries independently. Wayne's post seems to hit on this point. - At some point, I think this has already happened (jruby & java), build packs are going to start having overlapping sets of binaries. If the binaries are bundled with the build pack, there's no way that build packs could ever share binaries. My personal preference would be to see build packs bundled without binaries and some other solution, which probably merits a separate thread, for managing the binaries. I'm curious to hear what others think or if I've missed something and bundling build packs and binaries is clearly the way to go. Dan PS. If this is something that came up in the PMC, I apologize. I skimmed the notes, but may have missed it. On Mon, May 4, 2015 at 2:10 PM, Wayne E. Seguin < wayneeseguin(a)starkandwayne.com> wrote: Because of very good compatibility between versions (post 1.X) I would
like to make a motion to do the following:
Split the buildpack:
have the default golang buildpack track the latest golang version
Then handle older versions in one of two ways, either:
a) have a large secondary for older versions
or
b) have multiple, one for each version of golang, users can specify a
specific URL if they care about specific versions.
This would improve space/time considerations for operations. Personally I
would prefer b) because it allows you to enable supporting older go
versions out of the box by design but still keeping each golang buildpack
small.
~Wayne
Wayne E. Seguin <wayneeseguin(a)starkandwayne.com>
CTO ; Stark & Wayne, LLC
On May 4, 2015, at 12:40 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Hi Wayne,
On Fri, May 1, 2015 at 1:29 PM, Wayne E. Seguin <
wayneeseguin(a)starkandwayne.com> wrote:
What an incredible step in the right direction, Awesome!!!
Out of curiosity, why is the go buildpack still quite so large?
Thanks for asking this question.
Currently we're including the following binary dependencies in
`go-buildpack`:
```
cache $ ls -lSh *_go*
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.2.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
http___go.googlecode.com_files_go1.2.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.3.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.1.linux-amd64.tar.gz
```
One question we should ask, I think, is: should we still be supporting
golang 1.1 and 1.2? Dropping those versions would cut the size of the
buildpack in (approximately) half.
On May 1, 2015, at 11:54 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Skinny buildpacks have been cut for go, nodejs, php, python and ruby
buildpacks.
| | current | previous |
|--------+---------+----------|
| go | 442MB | 633MB |
| nodejs | 69MB | 417MB |
| php | 804MB | 1.1GB |
| python | 454MB | 654MB |
| ruby | 365MB | 1.3GB |
|--------+---------+----------|
| total | 2.1GB | 4.1GB |
for an aggregate 51% reduction in size. Details follow.
Next Steps
I recognize that every cloud operator may have a different policy on what
versions of interpreters and libraries they want to support, based on the
specific requirements of their users.
These buildpacks reflect a "bare mininum" policy for a cloud to be
operable, and I do not expect these buildpacks to be adopted as-is by many
operators.
These buildpacks have not yet been added to cf-release, specifically so
that the community can prepare their own buildpacks if necessary.
Over the next few days, the buildpacks core team will ship documentation
and tooling to assist you in packaging specific dependencies for your
instance of CF. I'll start a new thread on this list early next week to
communicate this information.
Call to Action
In the meantime, please think about whether the policy implemented in
these buildpacks ("last two patches (or teenies) on all supported
major.minor releases") is suitable for your users; and if not, think about
what dependencies you'll ideally be supporting.
go-buildpack v1.3.0
Release notes are here
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 633MB
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.2.0> to
442MB <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.
Supports (full manifest here
<https://github.com/cloudfoundry/go-buildpack/blob/v1.3.0/manifest.yml>):
- golang 1.4.{1,2}
- golang 1.3.{2,3}
- golang 1.2.{1,2}
- golang 1.1.{1,2}
nodejs-buildpack v1.3.0
Full release notes are here
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Size reduced 83% from 417MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.2.1>
to 69MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Supports (full manifest here
<https://github.com/cloudfoundry/nodejs-buildpack/blob/v1.3.0/manifest.yml>
):
- 0.8.{27,28}
- 0.9.{11,12}
- 0.10.{37,38}
- 0.11.{15,16}
- 0.12.{1,2}
php-buildpack v3.2.0
Full release notes are here
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>.
Size reduced 27% from 1.1GB
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.1.1> to
803MB <https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>
.
Supports: (full manifest here
<https://github.com/cloudfoundry/php-buildpack/blob/v3.2.0/manifest.yml>)
*PHP*:
- 5.6.{6,7}
- 5.5.{22,23}
- 5.4.{38,39}
*HHVM* (lucid64 stack):
- 3.2.0
*HHVM* (cflinuxfs2 stack):
- 3.5.{0,1}
- 3.6.{0,1}
*Apache HTTPD*:
- 2.4.12
*nginx*:
- 1.7.10
- 1.6.2
- 1.5.13
python-buildpack v1.3.0
Full release notes are here
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 654MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.2.0>
to 454MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Supports: (full manifest here
<https://github.com/cloudfoundry/python-buildpack/blob/v1.3.0/manifest.yml>
)
- 2.7.{8,9}
- 3.2.{4,5}
- 3.3.{5,6}
- 3.4.{2,3}
ruby-buildpack v1.4.0
Release notes are here
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Size reduced 71% from 1.3GB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.3.1> to
365MB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Supports: (full manifest here
<https://github.com/cloudfoundry/ruby-buildpack/blob/v1.4.0/manifest.yml>
)
*MRI*:
- 2.2.{1,2}
- 2.1.{5,6}
- 2.0.0p645
*JRuby*:
- ruby-1.9.3-jruby-1.7.19
- ruby-2.0.0-jruby-1.7.19
- ruby-2.2.0-jruby-9.0.0.0.pre1
---------- Forwarded message ----------
From: Mike Dalessio <mdalessio(a)pivotal.io>
Date: Wed, Apr 8, 2015 at 11:10 AM
Subject: Addressing buildpack size
To: vcap-dev(a)cloudfoundry.org
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
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Using Identity Zones with implicit flow
hi Brian, the task shouldn't be so difficult. Most languages already have some OAuth library to leverage that does all the work for you. And even without a library, Oauth is pretty straight forward. Just some HTTP calls with redirects. Are you looking for an example? pure HTTP example looks like: https://github.com/cloudfoundry/uaa/blob/develop/uaa/src/test/java/org/cloudfoundry/identity/uaa/integration/feature/ImplicitGrantIT.java#L78-L130Filip On Mon, May 4, 2015 at 9:08 PM, Brian Gaston <bgaston(a)learningsciences.com> wrote: Hello,
I hope I came to the right place. My apologies if I haven't. We are
working on a native mobile app and would like to leverage UAA for authz.
We have a multi-tenant environment and I was wondering how large of a task
it would be to get UAA implicit flow to work with client apps so we could
take full advantage of UAA's multi-tenancy support.
thanks so much.
Brian Gaston
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Using Identity Zones with implicit flow
Brian Gaston <bgaston@...>
Hello,
I hope I came to the right place. My apologies if I haven't. We are working on a native mobile app and would like to leverage UAA for authz. We have a multi-tenant environment and I was wondering how large of a task it would be to get UAA implicit flow to work with client apps so we could take full advantage of UAA's multi-tenancy support.
thanks so much.
Brian Gaston
|
|
|
Re: [vcap-dev] Proposal to bring Service Broker for Apache Brooklyn and CLI-Plugin into Incubator
Duncan Johnston-Watt <duncan.johnstonwatt@...>
Chip/All
Just following up on this proposal on the new list to get an update on its
status.
Best
Duncan
toggle quoted messageShow quoted text
--
Duncan Johnston-Watt
CEO | Cloudsoft Corporation
Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.com/in/duncanjohnstonwatt
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
|
|
|
UAA 2.2.5 & 2.2.6 Release
|
|
|
Re: Buildpacks PMC - 2015-05-04 Notes
Ryan Morgan <ryanmorgan@...>
Thanks for the update Mike. Can we get a bit more detail on java-buildpack
divergence from the other buildpacks?
-Ryan
toggle quoted messageShow quoted text
On Mon, May 4, 2015 at 10:50 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: Hi all,
We held the first Buildpacks PMC meeting today; I'd like to share the
agenda and notes.
For reference, all agendas notes for the Buildpacks PMC will be kept in a
public Google Drive folder at this URL:
http://bit.ly/cf-buildpacks-pmc
I realize GDrive isn't the most convenient medium for some in the CF
community; I'd love to hear how we can better support transparency for
everyone.
Please feel free to respond with comments and questions!
Cheers,
-m
----
Attendees:
-
Chip Childers, Cloud Foundry Foundation
-
Mike Dalessio, Pivotal (PMC lead)
-
Christopher Ferriss, IBM
-
Michael Fraenkel, IBM
-
Mark Kropf, Pivotal
Recent Inception Report and Stated Goals
The Buildpacks core development team held a project inception on
2015-04-20, to gain a shared understanding of upcoming goals and tracks of
work.
Goals
- Expand supported ecosystem to include more languages & frameworks
- Cloud Foundry ownership of Buildpacks
- Leverage new primitives in Diego (“app lifecycle”)
- Enable 3rd party extensions to the Developer experience
- Enable application developer extensions to the Developer
experience
- Set patterns for creating new buildpacks and for extending the
Developer experience
- Generate clearer diagnostics during staging
- Enable Operator ease of updating common dependencies
- Keep the `bin/detect` experience: buildpacks should Just Work™
- Exert more ownership over the rootfs
- Binary buildpack support
Risks
- java-buildpack is diverging quickly from the core buildpacks
- Lack of deep experience in some ecosystems
- Wide variety in implementations across buildpacks
- rootfs: with great power comes great responsibility (e.g.,
security response)
- tight coupling between buildpacks and rootfs
- versioning between buildpacks and rootfs
Current Backlog and Priorities
See https://www.pivotaltracker.com/n/projects/1042066
Notable near-term goals:
-
staticfile-buildpack support in `cf-release`
-
binary buildpack (a.k.a. “null buildpack”) support in `cf-release`
-
ability to generate and test CF rootfs-specific binaries; and tooling
for CF operators to do the same
Proposal: Buildpack Incubation Process
Discussion today for PMC input; a draft document will be circulated for
comment to cf-dev@ mailing list after the meeting, in a separate thread.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Addressing buildpack size
+1 Thanks for the great work! Over the next few days, the buildpacks core team will ship documentation and tooling to assist you in packaging specific dependencies for your instance of CF. I'll start a new thread on this list early next week to communicate this information. I hope this will be easy to customize as part of a bosh release configuration. Specifically, it would be even better if the cloud operator can customize some of the binary download URLs in the configuration, so that they can use their own binaries. As I know, many enterprises only use legal-cleared binary versions of open source components, hosted inside their firewall. I understand today this can be achieved by modifying the manifest.yml in each buildpack. But it would greater if it can be done through some build/package configuration. Jack On Mon, May 4, 2015 at 1:28 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote: the go community tends to move fast to adopt the latest versions of go. i
imagine we can drop 1.1 and 1.2 without impacting most people.
anyone on the list experience otherwise?
onsi
On Mon, May 4, 2015 at 9:40 AM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:
Hi Wayne,
On Fri, May 1, 2015 at 1:29 PM, Wayne E. Seguin <
wayneeseguin(a)starkandwayne.com> wrote:
What an incredible step in the right direction, Awesome!!!
Out of curiosity, why is the go buildpack still quite so large?
Thanks for asking this question.
Currently we're including the following binary dependencies in
`go-buildpack`:
```
cache $ ls -lSh *_go*
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.2.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
http___go.googlecode.com_files_go1.2.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.3.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.1.linux-amd64.tar.gz
```
One question we should ask, I think, is: should we still be supporting
golang 1.1 and 1.2? Dropping those versions would cut the size of the
buildpack in (approximately) half.
On May 1, 2015, at 11:54 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Skinny buildpacks have been cut for go, nodejs, php, python and ruby
buildpacks.
| | current | previous |
|--------+---------+----------|
| go | 442MB | 633MB |
| nodejs | 69MB | 417MB |
| php | 804MB | 1.1GB |
| python | 454MB | 654MB |
| ruby | 365MB | 1.3GB |
|--------+---------+----------|
| total | 2.1GB | 4.1GB |
for an aggregate 51% reduction in size. Details follow.
Next Steps
I recognize that every cloud operator may have a different policy on
what versions of interpreters and libraries they want to support, based on
the specific requirements of their users.
These buildpacks reflect a "bare mininum" policy for a cloud to be
operable, and I do not expect these buildpacks to be adopted as-is by many
operators.
These buildpacks have not yet been added to cf-release, specifically so
that the community can prepare their own buildpacks if necessary.
Over the next few days, the buildpacks core team will ship documentation
and tooling to assist you in packaging specific dependencies for your
instance of CF. I'll start a new thread on this list early next week to
communicate this information.
Call to Action
In the meantime, please think about whether the policy implemented in
these buildpacks ("last two patches (or teenies) on all supported
major.minor releases") is suitable for your users; and if not, think about
what dependencies you'll ideally be supporting.
go-buildpack v1.3.0
Release notes are here
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 633MB
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.2.0> to
442MB <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>
.
Supports (full manifest here
<https://github.com/cloudfoundry/go-buildpack/blob/v1.3.0/manifest.yml>
):
- golang 1.4.{1,2}
- golang 1.3.{2,3}
- golang 1.2.{1,2}
- golang 1.1.{1,2}
nodejs-buildpack v1.3.0
Full release notes are here
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Size reduced 83% from 417MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.2.1>
to 69MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Supports (full manifest here
<https://github.com/cloudfoundry/nodejs-buildpack/blob/v1.3.0/manifest.yml>
):
- 0.8.{27,28}
- 0.9.{11,12}
- 0.10.{37,38}
- 0.11.{15,16}
- 0.12.{1,2}
php-buildpack v3.2.0
Full release notes are here
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>.
Size reduced 27% from 1.1GB
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.1.1> to
803MB
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>.
Supports: (full manifest here
<https://github.com/cloudfoundry/php-buildpack/blob/v3.2.0/manifest.yml>
)
*PHP*:
- 5.6.{6,7}
- 5.5.{22,23}
- 5.4.{38,39}
*HHVM* (lucid64 stack):
- 3.2.0
*HHVM* (cflinuxfs2 stack):
- 3.5.{0,1}
- 3.6.{0,1}
*Apache HTTPD*:
- 2.4.12
*nginx*:
- 1.7.10
- 1.6.2
- 1.5.13
python-buildpack v1.3.0
Full release notes are here
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 654MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.2.0>
to 454MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Supports: (full manifest here
<https://github.com/cloudfoundry/python-buildpack/blob/v1.3.0/manifest.yml>
)
- 2.7.{8,9}
- 3.2.{4,5}
- 3.3.{5,6}
- 3.4.{2,3}
ruby-buildpack v1.4.0
Release notes are here
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Size reduced 71% from 1.3GB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.3.1> to
365MB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Supports: (full manifest here
<https://github.com/cloudfoundry/ruby-buildpack/blob/v1.4.0/manifest.yml>
)
*MRI*:
- 2.2.{1,2}
- 2.1.{5,6}
- 2.0.0p645
*JRuby*:
- ruby-1.9.3-jruby-1.7.19
- ruby-2.0.0-jruby-1.7.19
- ruby-2.2.0-jruby-9.0.0.0.pre1
---------- Forwarded message ----------
From: Mike Dalessio <mdalessio(a)pivotal.io>
Date: Wed, Apr 8, 2015 at 11:10 AM
Subject: Addressing buildpack size
To: vcap-dev(a)cloudfoundry.org
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
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Chip Childers <cchilders@...>
I've asked to have the limit increased. Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation On Mon, May 4, 2015 at 2:39 PM, Wayne E. Seguin < wayneeseguin(a)starkandwayne.com> wrote: So it appears that when you reply to longer messages on the mailing list
it gets held? My actual text is only about a paragraph’s worth.
Wayne E. Seguin <wayneeseguin(a)starkandwayne.com>
CTO ; Stark & Wayne, LLC
Begin forwarded message:
*From: *cf-dev-bounces(a)lists.cloudfoundry.org
*Subject: **Your message to cf-dev awaits moderator approval*
*Date: *May 4, 2015 at 14:35:40 EDT
*To: *wayneeseguin(a)starkandwayne.com
Your mail to 'cf-dev' with the subject
Re: [cf-dev] Fwd: Addressing buildpack size
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 41288 bytes with a limit of 40 KB
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:
https://lists.cloudfoundry.org/mailman/confirm/cf-dev/e383436707127c121c059ab55c3b52b0e6804cbf
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
So it appears that when you reply to longer messages on the mailing list it gets held? My actual text is only about a paragraph’s worth.
Wayne E. Seguin <wayneeseguin(a)starkandwayne.com <mailto:wayneeseguin(a)starkandwayne.com>>
CTO ; Stark & Wayne, LLC
toggle quoted messageShow quoted text
Begin forwarded message:
From: cf-dev-bounces(a)lists.cloudfoundry.org
Subject: Your message to cf-dev awaits moderator approval
Date: May 4, 2015 at 14:35:40 EDT
To: wayneeseguin(a)starkandwayne.com
Your mail to 'cf-dev' with the subject
Re: [cf-dev] Fwd: Addressing buildpack size
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 41288 bytes with a limit of 40 KB
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:
https://lists.cloudfoundry.org/mailman/confirm/cf-dev/e383436707127c121c059ab55c3b52b0e6804cbf
|
|
|
Re: Buildpacks PMC - 2015-05-04 Notes
toggle quoted messageShow quoted text
On Mon, May 4, 2015 at 10:50 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: Hi all,
We held the first Buildpacks PMC meeting today; I'd like to share the
agenda and notes.
For reference, all agendas notes for the Buildpacks PMC will be kept in a
public Google Drive folder at this URL:
http://bit.ly/cf-buildpacks-pmc
I realize GDrive isn't the most convenient medium for some in the CF
community; I'd love to hear how we can better support transparency for
everyone.
Please feel free to respond with comments and questions!
Cheers,
-m
----
Attendees:
-
Chip Childers, Cloud Foundry Foundation
-
Mike Dalessio, Pivotal (PMC lead)
-
Christopher Ferriss, IBM
-
Michael Fraenkel, IBM
-
Mark Kropf, Pivotal
Recent Inception Report and Stated Goals
The Buildpacks core development team held a project inception on
2015-04-20, to gain a shared understanding of upcoming goals and tracks of
work.
Goals
- Expand supported ecosystem to include more languages & frameworks
- Cloud Foundry ownership of Buildpacks
- Leverage new primitives in Diego (“app lifecycle”)
- Enable 3rd party extensions to the Developer experience
- Enable application developer extensions to the Developer
experience
- Set patterns for creating new buildpacks and for extending the
Developer experience
- Generate clearer diagnostics during staging
- Enable Operator ease of updating common dependencies
- Keep the `bin/detect` experience: buildpacks should Just Work™
- Exert more ownership over the rootfs
- Binary buildpack support
Risks
- java-buildpack is diverging quickly from the core buildpacks
- Lack of deep experience in some ecosystems
- Wide variety in implementations across buildpacks
- rootfs: with great power comes great responsibility (e.g.,
security response)
- tight coupling between buildpacks and rootfs
- versioning between buildpacks and rootfs
Current Backlog and Priorities
See https://www.pivotaltracker.com/n/projects/1042066
Notable near-term goals:
-
staticfile-buildpack support in `cf-release`
-
binary buildpack (a.k.a. “null buildpack”) support in `cf-release`
-
ability to generate and test CF rootfs-specific binaries; and tooling
for CF operators to do the same
Proposal: Buildpack Incubation Process
Discussion today for PMC input; a draft document will be circulated for
comment to cf-dev@ mailing list after the meeting, in a separate thread.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Buildpacks PMC - 2015-05-04 Notes
The biggest issue with GDrive is that our folks in China can’t easily view them ;)
My question/feedback comes from the other recent thread about buildpack sizing and efficiency. I did not see a bullet point in the list below for this (unless it was covered by different wording/terminology). I would love to see a way where buildpacks can become smaller not bigger whilst still supporting the vast array of languages+versions.
Thank you for including them in this email and thank you for keeping us all in the loop, much appreciated!
~Wayne
Wayne E. Seguin <wayneeseguin(a)starkandwayne.com <mailto:wayneeseguin(a)starkandwayne.com>>
CTO ; Stark & Wayne, LLC
toggle quoted messageShow quoted text
On May 4, 2015, at 13:50 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Hi all,
We held the first Buildpacks PMC meeting today; I'd like to share the agenda and notes.
For reference, all agendas notes for the Buildpacks PMC will be kept in a public Google Drive folder at this URL:
http://bit.ly/cf-buildpacks-pmc <http://bit.ly/cf-buildpacks-pmc>
I realize GDrive isn't the most convenient medium for some in the CF community; I'd love to hear how we can better support transparency for everyone.
Please feel free to respond with comments and questions!
Cheers,
-m
----
Attendees:
Chip Childers, Cloud Foundry Foundation
Mike Dalessio, Pivotal (PMC lead)
Christopher Ferriss, IBM
Michael Fraenkel, IBM
Mark Kropf, Pivotal
Recent Inception Report and Stated Goals
The Buildpacks core development team held a project inception on 2015-04-20, to gain a shared understanding of upcoming goals and tracks of work.
Goals
Expand supported ecosystem to include more languages & frameworks
Cloud Foundry ownership of Buildpacks
Leverage new primitives in Diego (“app lifecycle”)
Enable 3rd party extensions to the Developer experience
Enable application developer extensions to the Developer experience
Set patterns for creating new buildpacks and for extending the Developer experience
Generate clearer diagnostics during staging
Enable Operator ease of updating common dependencies
Keep the `bin/detect` experience: buildpacks should Just Work™
Exert more ownership over the rootfs
Binary buildpack support
Risks
java-buildpack is diverging quickly from the core buildpacks
Lack of deep experience in some ecosystems
Wide variety in implementations across buildpacks
rootfs: with great power comes great responsibility (e.g., security response)
tight coupling between buildpacks and rootfs
versioning between buildpacks and rootfs
Current Backlog and Priorities
See https://www.pivotaltracker.com/n/projects/1042066 <https://www.pivotaltracker.com/n/projects/1042066>
Notable near-term goals:
staticfile-buildpack support in `cf-release`
binary buildpack (a.k.a. “null buildpack”) support in `cf-release`
ability to generate and test CF rootfs-specific binaries; and tooling for CF operators to do the same
Proposal: Buildpack Incubation Process
Discussion today for PMC input; a draft document will be circulated for comment to cf-dev@ mailing list after the meeting, in a separate thread.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Addressing buildpack size
Because of very good compatibility between versions (post 1.X) I would like to make a motion to do the following:
Split the buildpack:
have the default golang buildpack track the latest golang version
Then handle older versions in one of two ways, either:
a) have a large secondary for older versions
or
b) have multiple, one for each version of golang, users can specify a specific URL if they care about specific versions.
This would improve space/time considerations for operations. Personally I would prefer b) because it allows you to enable supporting older go versions out of the box by design but still keeping each golang buildpack small.
~Wayne
Wayne E. Seguin <wayneeseguin(a)starkandwayne.com <mailto:wayneeseguin(a)starkandwayne.com>>
CTO ; Stark & Wayne, LLC
toggle quoted messageShow quoted text
On May 4, 2015, at 12:40 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Hi Wayne,
On Fri, May 1, 2015 at 1:29 PM, Wayne E. Seguin <wayneeseguin(a)starkandwayne.com <mailto:wayneeseguin(a)starkandwayne.com>> wrote:
What an incredible step in the right direction, Awesome!!!
Out of curiosity, why is the go buildpack still quite so large?
Thanks for asking this question.
Currently we're including the following binary dependencies in `go-buildpack`:
```
cache $ ls -lSh *_go*
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36 https___storage.googleapis.com_golang_go1.4.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36 https___storage.googleapis.com_golang_go1.4.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36 https___storage.googleapis.com_golang_go1.2.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36 http___go.googlecode.com_files_go1.2.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36 https___storage.googleapis.com_golang_go1.3.3.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36 https___storage.googleapis.com_golang_go1.3.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36 http___go.googlecode.com_files_go1.1.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36 http___go.googlecode.com_files_go1.1.1.linux-amd64.tar.gz
```
One question we should ask, I think, is: should we still be supporting golang 1.1 and 1.2? Dropping those versions would cut the size of the buildpack in (approximately) half.
On May 1, 2015, at 11:54 , Mike Dalessio <mdalessio(a)pivotal.io <mailto:mdalessio(a)pivotal.io>> wrote:
Skinny buildpacks have been cut for go, nodejs, php, python and ruby buildpacks.
| | current | previous |
|--------+---------+----------|
| go | 442MB | 633MB |
| nodejs | 69MB | 417MB |
| php | 804MB | 1.1GB |
| python | 454MB | 654MB |
| ruby | 365MB | 1.3GB |
|--------+---------+----------|
| total | 2.1GB | 4.1GB |
for an aggregate 51% reduction in size. Details follow.
Next Steps
I recognize that every cloud operator may have a different policy on what versions of interpreters and libraries they want to support, based on the specific requirements of their users.
These buildpacks reflect a "bare mininum" policy for a cloud to be operable, and I do not expect these buildpacks to be adopted as-is by many operators.
These buildpacks have not yet been added to cf-release, specifically so that the community can prepare their own buildpacks if necessary.
Over the next few days, the buildpacks core team will ship documentation and tooling to assist you in packaging specific dependencies for your instance of CF. I'll start a new thread on this list early next week to communicate this information.
Call to Action
In the meantime, please think about whether the policy implemented in these buildpacks ("last two patches (or teenies) on all supported major.minor releases") is suitable for your users; and if not, think about what dependencies you'll ideally be supporting.
go-buildpack v1.3.0
Release notes are here <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 633MB <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.2.0> to 442MB <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.
Supports (full manifest here <https://github.com/cloudfoundry/go-buildpack/blob/v1.3.0/manifest.yml>):
golang 1.4.{1,2}
golang 1.3.{2,3}
golang 1.2.{1,2}
golang 1.1.{1,2}
nodejs-buildpack v1.3.0
Full release notes are here <https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Size reduced 83% from 417MB <https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.2.1> to 69MB <https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Supports (full manifest here <https://github.com/cloudfoundry/nodejs-buildpack/blob/v1.3.0/manifest.yml>):
0.8.{27,28}
0.9.{11,12}
0.10.{37,38}
0.11.{15,16}
0.12.{1,2}
php-buildpack v3.2.0
Full release notes are here <https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>.
Size reduced 27% from 1.1GB <https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.1.1> to 803MB <https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>.
Supports: (full manifest here <https://github.com/cloudfoundry/php-buildpack/blob/v3.2.0/manifest.yml>)
PHP:
5.6.{6,7}
5.5.{22,23}
5.4.{38,39}
HHVM (lucid64 stack):
3.2.0
HHVM (cflinuxfs2 stack):
3.5.{0,1}
3.6.{0,1}
Apache HTTPD:
2.4.12
nginx:
1.7.10
1.6.2
1.5.13
python-buildpack v1.3.0
Full release notes are here <https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 654MB <https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.2.0> to 454MB <https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Supports: (full manifest here <https://github.com/cloudfoundry/python-buildpack/blob/v1.3.0/manifest.yml>)
2.7.{8,9}
3.2.{4,5}
3.3.{5,6}
3.4.{2,3}
ruby-buildpack v1.4.0
Release notes are here <https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Size reduced 71% from 1.3GB <https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.3.1> to 365MB <https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Supports: (full manifest here <https://github.com/cloudfoundry/ruby-buildpack/blob/v1.4.0/manifest.yml>)
MRI:
2.2.{1,2}
2.1.{5,6}
2.0.0p645
JRuby:
ruby-1.9.3-jruby-1.7.19
ruby-2.0.0-jruby-1.7.19
ruby-2.2.0-jruby-9.0.0.0.pre1
---------- Forwarded message ----------
From: Mike Dalessio <mdalessio(a)pivotal.io <mailto:mdalessio(a)pivotal.io>>
Date: Wed, Apr 8, 2015 at 11:10 AM
Subject: Addressing buildpack size
To: vcap-dev(a)cloudfoundry.org <mailto:vcap-dev(a)cloudfoundry.org>
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 <https://github.com/cloudfoundry-incubator/buildpack-packager/issues/4>
Feel free to comment there or reply to this email.
Buildpack Sizes
Where 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:
For language interpreters/compilers, we'll package the two most-recent TEENY versions on each MAJOR.MINOR release.
For all other dependencies, we'll package only the single most-recent TEENY version on each MAJOR.MINOR release.
We will discontinue packaging versions of dependencies that have been deprecated.
We will no longer provide "EVOEES" buildpack releases.
We will no longer provide "online" buildpack releases, which download dependencies from the public internet.
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 <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
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org <mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev <https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>
|
|
|
Buildpacks PMC - 2015-05-04 Notes
Hi all, We held the first Buildpacks PMC meeting today; I'd like to share the agenda and notes. For reference, all agendas notes for the Buildpacks PMC will be kept in a public Google Drive folder at this URL: http://bit.ly/cf-buildpacks-pmcI realize GDrive isn't the most convenient medium for some in the CF community; I'd love to hear how we can better support transparency for everyone. Please feel free to respond with comments and questions! Cheers, -m ---- Attendees: - Chip Childers, Cloud Foundry Foundation - Mike Dalessio, Pivotal (PMC lead) - Christopher Ferriss, IBM - Michael Fraenkel, IBM - Mark Kropf, Pivotal Recent Inception Report and Stated Goals The Buildpacks core development team held a project inception on 2015-04-20, to gain a shared understanding of upcoming goals and tracks of work. Goals - Expand supported ecosystem to include more languages & frameworks - Cloud Foundry ownership of Buildpacks - Leverage new primitives in Diego (“app lifecycle”) - Enable 3rd party extensions to the Developer experience - Enable application developer extensions to the Developer experience - Set patterns for creating new buildpacks and for extending the Developer experience - Generate clearer diagnostics during staging - Enable Operator ease of updating common dependencies - Keep the `bin/detect` experience: buildpacks should Just Work™ - Exert more ownership over the rootfs - Binary buildpack support Risks - java-buildpack is diverging quickly from the core buildpacks - Lack of deep experience in some ecosystems - Wide variety in implementations across buildpacks - rootfs: with great power comes great responsibility (e.g., security response) - tight coupling between buildpacks and rootfs - versioning between buildpacks and rootfs Current Backlog and Priorities See https://www.pivotaltracker.com/n/projects/1042066Notable near-term goals: - staticfile-buildpack support in `cf-release` - binary buildpack (a.k.a. “null buildpack”) support in `cf-release` - ability to generate and test CF rootfs-specific binaries; and tooling for CF operators to do the same Proposal: Buildpack Incubation Process Discussion today for PMC input; a draft document will be circulated for comment to cf-dev@ mailing list after the meeting, in a separate thread.
|
|
|
Re: Addressing buildpack size
Onsi Fakhouri <ofakhouri@...>
the go community tends to move fast to adopt the latest versions of go. i
imagine we can drop 1.1 and 1.2 without impacting most people.
anyone on the list experience otherwise?
onsi
toggle quoted messageShow quoted text
On Mon, May 4, 2015 at 9:40 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: Hi Wayne,
On Fri, May 1, 2015 at 1:29 PM, Wayne E. Seguin <
wayneeseguin(a)starkandwayne.com> wrote:
What an incredible step in the right direction, Awesome!!!
Out of curiosity, why is the go buildpack still quite so large?
Thanks for asking this question.
Currently we're including the following binary dependencies in
`go-buildpack`:
```
cache $ ls -lSh *_go*
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.2.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
http___go.googlecode.com_files_go1.2.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.3.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.1.linux-amd64.tar.gz
```
One question we should ask, I think, is: should we still be supporting
golang 1.1 and 1.2? Dropping those versions would cut the size of the
buildpack in (approximately) half.
On May 1, 2015, at 11:54 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Skinny buildpacks have been cut for go, nodejs, php, python and ruby
buildpacks.
| | current | previous |
|--------+---------+----------|
| go | 442MB | 633MB |
| nodejs | 69MB | 417MB |
| php | 804MB | 1.1GB |
| python | 454MB | 654MB |
| ruby | 365MB | 1.3GB |
|--------+---------+----------|
| total | 2.1GB | 4.1GB |
for an aggregate 51% reduction in size. Details follow.
Next Steps
I recognize that every cloud operator may have a different policy on what
versions of interpreters and libraries they want to support, based on the
specific requirements of their users.
These buildpacks reflect a "bare mininum" policy for a cloud to be
operable, and I do not expect these buildpacks to be adopted as-is by many
operators.
These buildpacks have not yet been added to cf-release, specifically so
that the community can prepare their own buildpacks if necessary.
Over the next few days, the buildpacks core team will ship documentation
and tooling to assist you in packaging specific dependencies for your
instance of CF. I'll start a new thread on this list early next week to
communicate this information.
Call to Action
In the meantime, please think about whether the policy implemented in
these buildpacks ("last two patches (or teenies) on all supported
major.minor releases") is suitable for your users; and if not, think about
what dependencies you'll ideally be supporting.
go-buildpack v1.3.0
Release notes are here
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 633MB
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.2.0> to
442MB <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.
Supports (full manifest here
<https://github.com/cloudfoundry/go-buildpack/blob/v1.3.0/manifest.yml>):
- golang 1.4.{1,2}
- golang 1.3.{2,3}
- golang 1.2.{1,2}
- golang 1.1.{1,2}
nodejs-buildpack v1.3.0
Full release notes are here
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Size reduced 83% from 417MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.2.1>
to 69MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.
Supports (full manifest here
<https://github.com/cloudfoundry/nodejs-buildpack/blob/v1.3.0/manifest.yml>
):
- 0.8.{27,28}
- 0.9.{11,12}
- 0.10.{37,38}
- 0.11.{15,16}
- 0.12.{1,2}
php-buildpack v3.2.0
Full release notes are here
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>.
Size reduced 27% from 1.1GB
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.1.1> to
803MB <https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>
.
Supports: (full manifest here
<https://github.com/cloudfoundry/php-buildpack/blob/v3.2.0/manifest.yml>)
*PHP*:
- 5.6.{6,7}
- 5.5.{22,23}
- 5.4.{38,39}
*HHVM* (lucid64 stack):
- 3.2.0
*HHVM* (cflinuxfs2 stack):
- 3.5.{0,1}
- 3.6.{0,1}
*Apache HTTPD*:
- 2.4.12
*nginx*:
- 1.7.10
- 1.6.2
- 1.5.13
python-buildpack v1.3.0
Full release notes are here
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Size reduced 30% from 654MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.2.0>
to 454MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.
Supports: (full manifest here
<https://github.com/cloudfoundry/python-buildpack/blob/v1.3.0/manifest.yml>
)
- 2.7.{8,9}
- 3.2.{4,5}
- 3.3.{5,6}
- 3.4.{2,3}
ruby-buildpack v1.4.0
Release notes are here
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Size reduced 71% from 1.3GB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.3.1> to
365MB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.
Supports: (full manifest here
<https://github.com/cloudfoundry/ruby-buildpack/blob/v1.4.0/manifest.yml>
)
*MRI*:
- 2.2.{1,2}
- 2.1.{5,6}
- 2.0.0p645
*JRuby*:
- ruby-1.9.3-jruby-1.7.19
- ruby-2.0.0-jruby-1.7.19
- ruby-2.2.0-jruby-9.0.0.0.pre1
---------- Forwarded message ----------
From: Mike Dalessio <mdalessio(a)pivotal.io>
Date: Wed, Apr 8, 2015 at 11:10 AM
Subject: Addressing buildpack size
To: vcap-dev(a)cloudfoundry.org
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
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
