Present Buildpacks to the TOC #122

Closed sclevine closed 6 years ago

Buildpacks replace Dockerfiles in the app development lifecycle with a higher level of abstraction. In doing so, they provide a balance of control that reduces the operational burden on developers and supports enterprise operators who manage apps at scale. Buildpacks ensure that apps meet security and compliance requirements without developer intervention. They provide automated delivery of both OS-level and application-level dependency upgrades, efficiently handling day-2 app operations that are often difficult to manage with Dockerfiles.

First conceived in 2012, buildpacks have provided an opinionated solution for building cloud apps on Heroku, Cloud Foundry, GitLab, Deis, Dokku, and other platforms. Heroku and Pivotal are actively collaborating on a next-generation buildpack API that uses existing standards (such as the OCI image format) to bring buildpacks to cloud platforms that support Docker or OCI images. This new API also incorporates feedback from years of assisting our customers operate buildpacks in production.

We believe this project fits well within the CNCF by directly supporting the CNCF's mission statement of supporting cloud native systems. The next generation of buildpacks will aid developers and operators in packaging applications into containers (1a), allow operators to efficiently manage the infrastructure necessary to keep application dependencies updated (1b), and are available via well-defined interfaces (1c).

By becoming a CNCF project, we hope to greatly improve buildpack interoperability between platforms and attract a wide community of contributors, including buildpack creators and maintainers.

GitHub: https://github.com/buildpack/resources License: Apache License, Version 2.0 (Website will be packs.sh.)

@sclevine can you elaborate on where, or what, this "project" is? The url to github you provided is just to a README. All of the links in there go to other sites. Are you proposing a project that has code - and if so, where is it? or are you suggesting we pick-up the CF code base? Or is this project a specification? the CF spec? the heroku spec?

RFC @cncf/toc

If I don't hear anything against scheduling from the TOC by end of next week, how does Aug 21st work at 8am PT?

@duglin We intend to contribute a specification for a new buildpack interface that adopts cloud native principles and standards, a corresponding reference implementation, and a set of tools. We don't currently plan to contribute existing buildpacks.

Apologies for the lack of clarity -- this is an early-stage project intended for the sandbox, and we plan to publish more before presenting to the TOC.

Great, thanks for the clarification.

Sent from my iPad

On Jun 9, 2018, at 12:01 AM, Stephen Levine notifications@github.com wrote:

@duglin We intend to contribute a specification for a new buildpack interface that adopts cloud native principles and standards, a corresponding reference implementation, and a set of tools. We don't currently plan to contribute existing buildpacks.

Apologies for the lack of clarity -- this is an early-stage project intended for the sandbox, and we plan to publish more before presenting to the TOC.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

What's a good place for folks to contribute to this effort?

@sclevine Could you please speak to why Heroku and Cloud Foundry are not planning to contribute the existing buildpacks?

@sclevine you can present to the TOC on August 21st if that works at 8am PT

@dankohn I'll let @sclevine and the Heroku folks reply as well, but generally think about buildpacks as artifacts that are designed to be varied across users and use cases. An imperfect analogy would be Dockerfiles. There's discussion in the works around a buildpack registry to help with discoverability across the ecosystem of buildpack authors.

What matters is the standardization of the API and reference implementations of that API that can support using any buildpack that conforms to the standard.

I agree that you can treat buildpacks as opaque and just standardize the interfaces for them. However, I know from experience that there are thousands of hours of engineering invested in, say, the internals of the Ruby or Node.js buildpacks. I would think that CF and Heroku might want to collaborate to share that engineering rather than maintain their own buildpacks. But perhaps that collaboration could come later.

-- Dan Kohn dan@linuxfoundation.org Executive Director, Cloud Native Computing Foundation https://www.cncf.io +1-415-233-1000 https://www.dankohn.com

On Tue, Jun 12, 2018 at 12:53 PM, Chip Childers notifications@github.com wrote:

@dankohn https://github.com/dankohn I'll let @sclevine https://github.com/sclevine and the Heroku folks reply as well, but generally think about buildpacks as artifacts that are designed to be varied across users and use cases. An imperfect analogy would be Dockerfiles. There's discussion in the works around a buildpack registry to help with discoverability across the ecosystem of buildpack authors.

What matters is the standardization of the API and reference implementations of that API that can support using any buildpack that conforms to the standard.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cncf/toc/issues/122#issuecomment-396659703, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8MBlF_gIISGktkONciJG_zjMAv0Ociks5t7_HygaJpZM4Ug-FV .

@caniszczyk August 21 at 8am PT works for everyone, thanks!

@dankohn The new specification pushes a chunk of common buildpack functionality into the lifecycle (the program that runs in the build container and implements the spec) so that authoring a simple buildpack is relatively easy. It also has built-in support for inline buildpacks, so that developers can still take advantage of the buildpack model (ex. automatic OS-level patches) without overhead when they need more flexibility than existing buildpacks provide.

We plan to create a registry for buildpacks with a degree of curation, but we don't have immediate plans to include existing buildpacks in the project itself. We may re-evaluate this once the Cloud Foundry and Heroku buildpacks adopt the new specification. We want buildpacks to be a comprehensive solution for building app images, but we also believe that having more than one implementation of a Ruby buildpack or Node.js buildpack that implements the new specification initially will help us drive out an interface that is generic and interoperable.

We've still actively collaborating on the new specification, but we've made it viewable here for those interested in reviewing it before we open the doc up for public comment. I've also started work on a reference implementation here.

scheduled to present Aug 21st at 8am PT

@bgrant0607 and @monadic are happy to sponsor this in the sandbox

@sclevine can you put forth a project proposal and issue a PR against the TOC repo?

Thanks @bgrant0607 and @monadic! Don't hesitate to reach out to us if you have any questions about the project. We really appreciate your interest! 😄

@caniszczyk Will do ASAP.

@caniszczyk proposed here: https://github.com/cncf/toc/pull/150

cncf / toc

Present Buildpacks to the TOC #122