Date
1 - 4 of 4
Buildpacks PMC - 2015-10-12 Notes
|
Mike Dalessio
Hello CF community,
Here is an update from the Buildpacks PMC, as of 2015-10-12. The full notes are available at https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md but I've reproduced them below in their entirety for your convenience. *Please note* that there are three proposals below for which we're requesting comments from the community. We invite comments and concerns, as well as alternative solutions, in the Github Issues that are linked to below. Cheers, -mike ----- Buildpacks PMC Notes as of 2015-10-08 The last set of notes were sent out on 2015-09-09 <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#table-of-contents>Table of Contents 1. Update on Stacks 2. Update on Buildpacks 1. General 2. java-buildpack 3. go-buildpack 4. php-buildpack 5. python-buildpack <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#stacks> Stacks <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#releases> Releases Released cflinuxfs2 1.9.0 <https://github.com/cloudfoundry/stacks/releases/tag/1.9.0> and 1.8.0 <https://github.com/cloudfoundry/stacks/releases/tag/1.8.0>, which address USN-2740-1 <http://www.ubuntu.com/usn/usn-2740-1>, "ICU vulnerabilities" and USN-2739-1 <http://www.ubuntu.com/usn/usn-2739-1>, "FreeType vulnerabilities". <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#buildpacks> Buildpacks <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#general> General The Buildpacks team has been doing further experimentation with *extensibility* for both developers and operators. Results can be seen in the public Tracker under the "architecture" epic <https://www.pivotaltracker.com/epic/show/1898760>. The Buildpacks team has also been working on a feature track to allow end users of the core buildpacks to *verify the origin* of all binaries vendored in the buildpack. This "chain of custody" track is intended to allow security-minded CF operators to trust the buildpack binaries being run in their deployment (and to regenerate the binaries themselves as needed). This work can be viewed in the public Tracker under the "chain of custody" epic <https://www.pivotaltracker.com/epic/show/2077742>. <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#java-buildpack> java-buildpack <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#releases-1> Releases Released java-buildpack 3.2 <https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.2> and 3.3 <https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.3>. These buildpacks add Luna HA support, as well as deliver improvements to the memory calculator. Please view the release notes <https://github.com/cloudfoundry/java-buildpack/releases> for full details. <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#go-buildpack> go-buildpack <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#releases-2> Releases Released go-buildpack v1.6.1 <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.6.1> and v1.6.2 <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.6.2>. These releases add support for golang 1.5.1 and golang 1.4.3, which addresses a number of CVEs in 1.4.2 and earlier. Support for golang 1.4.1 was dropped. Please view the release notes <https://github.com/cloudfoundry/go-buildpack/releases> for full details. <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#proposals> Proposals *Proposal:* It is being proposed to drop support for golang 1.2.x and 1.3.x. We're using a Github Issue as an RFC, so please comment here: https://github.com/cloudfoundry/go-buildpack/issues/22 <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#php-buildpack> php-buildpack <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#releases-3> Releases Released v4.1.5 <https://github.com/cloudfoundry/php-buildpack/releases/tag/v4.1.5>, v4.1.4 <https://github.com/cloudfoundry/php-buildpack/releases/tag/v4.1.4>, and v4.1.3 <https://github.com/cloudfoundry/php-buildpack/releases/tag/v4.1.3> which: - updates to nginx 1.9.5, - updates to PHP 5.6.14, 5.6.13, 5.5.30, 5.5.29, and 5.4.45. - addresses USN-2740-1 "ICU vulnerabilities" (in combination with rootfs 1.9.0) Please view the release notes <https://github.com/cloudfoundry/php-buildpack/releases> for full details. <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#end-of-life>End of Life *Please note that PHP 5.4 reached "End of Life" on 2015-09-14*. We intend to remove support for this version of PHP in the next release of the php-buildpack. <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#proposals-1> Proposals *Proposal:* It is being proposed to drop support for nginx 1.6 (but keeping support for nginx 1.8 and 1.9). We're using a Github Issue as an RFC, so please comment here: https://github.com/cloudfoundry/php-buildpack/issues/109 <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#python-buildpack> python-buildpack <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#releases-4> Releases Released v1.5.1 <https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.5.1> which adds support for Python 3.5.0. Please view the release notes <https://github.com/cloudfoundry/python-buildpack/releases> for full details. <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#nodejs-buildpack> nodejs-buildpack <https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-10-12-buildpacks.md#proposals-2> Proposals *Proposal:* It is being proposed to add Node 4.x support by statically linking against openssl 1.0.2. This introduces a requirement to restage applications running Node 4.x to address openssl CVEs. (Currently, only a rootfs update is needed for this scenario.) We're using a Github Issue as an RFC, so please comment here: https://github.com/cloudfoundry/nodejs-buildpack/issues/32 |
|
|
|
Hi Mike,
Thanks for sharing the buildpacks PMC notes. Related to the architecture epic, What's the outcome of this epic and the general direction the buildpack team is taking for pluggeable staging pipeline ? The Experiment #5 [3] relying on environment variables POST_BUILDPACK seems pretty promising. Would it support an orderer list of post buildpacks ? Concerning the story "Experiment #6: Investigate using a pluggable / web services model for extending staging to operators and developers" [1] we had discussed together into [2]. The story is marked as accepted, but I can't see the result, and future work, including how this could be exposed to CF operators or users. Can you share with the community a summary of learnings from these experiments and where the "buildpack lifecycle" would be go in the future? Thanks, Guillaume. [1] https://www.pivotaltracker.com/story/show/100758730 [2] http://cf-dev.70369.x6.nabble.com/cf-dev-Droplets-and-Stacks-tp946p1096.html [3] https://www.pivotaltracker.com/story/show/99820204 On Mon, Oct 12, 2015 at 11:33 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: Hello CF community, |
|
|
|
Mike Dalessio
Hello Guillaume,
Thanks for asking these questions! On Wed, Oct 14, 2015 at 3:32 AM, Guillaume Berche <bercheg(a)gmail.com> wrote: Hi Mike,We're having some discussions now as to next steps. Ideally I'd like to identify a track of feature work that will drive out a set of features for extending the buildpack staging lifecycle. If you or anyone else has suggestions, I'm all ears. No reason it couldn't support an ordered set of buildpacks. I'm not fully convinced this is the best way to proceed, but it's certainly the easiest, and we're looking at it pretty hard at this point. This experiment was cut short, as the "web hook" model introduced too many reliability concerns, in my opinion, especially around relying on external services to stage an app. I'm open to revisiting it in the future, but would like to try more pedestrian solutions first. Absolutely, I will do so soon.
|
|
|
|
Thanks Mike for your response and sorry for delay in following up.
Responses inline. On Wed, Oct 14, 2015 at 3:18 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: Following are some aspects that were previously discussed and I think deserve some fixes related to buildpack staging life cycle, what about setting up a design proposal as suggested by James Bayer into [0] to detail them with the community ? - buildpack versionning [b1] - offer standard caching mechanism for pulled internet dependencies [b2] - enabling buildpack debugging traces could be standardized across buildpacks and potentially support added to cf cli and dea, e.g. displaying last git commits for a custom git repo when debugging is enabled - heroku compile ENV_DIR compatibility support in diego [b3] - support for automatically restaging vulnerable apps, once corresponding buildpacks vulnerabilities are fixed by a new buildpack [b4] - buildpack governance support: in some organizations, there is a need to scope some buildpacks per org/spaces, and possibly restrict usage of custom buildpacks. - somewhat related, suggesting to improve the droplet download capability to push the resulting droplet as a docket image into a [private] docker repo. This might seem more natural than the current download tar.gz droplet bits followed by a push to the binary buildpack that is suffering from symlinks uploads portability issues [b5] [b0] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/A84xVoi8MmE/mos1CYvnxvAJ [b1] http://cf-dev.70369.x6.nabble.com/cf-dev-Droplets-and-Stacks-tp946p2422.html [b2] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/A84xVoi8MmE/AuQt3nF3ImcJ [b3] https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle/issues/12 [b4] https://github.com/cloudfoundry/java-buildpack/issues/231#issuecomment-142200625 [b5] https://www.pivotaltracker.com/n/projects/966314/stories/95890146 Can you please elaborate on your perception of reliability concerns with anNo reason it couldn't support an ordered set of buildpacks. I'm not fully HTTP-based API for staging pipelines ? CloudFoundry currently heavily relies on (internal) HTTP APIs for its internal workings, or external HTTP APIs such as the service broker, or the upcoming route services. What is then the preferred solution for now ? Is the mention of an S3-API-based pipeline with processes handling their transformation, similar to the proof-of-concept vito proposed into [p1] [p1] https://github.com/vito/cfv4 ? If ever you or part of the buildpacks team is making it to the Berlin CfAbsolutely, I will do so soon. Summit, that'd be great to have a community session around this, possibly in the preceding unconference on sunday. |
|
|