New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Present Buildpacks to the TOC #122

Closed
sclevine opened this Issue Jun 8, 2018 · 14 comments

Comments

Projects
None yet
6 participants
@sclevine

sclevine commented Jun 8, 2018

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.)

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Jun 8, 2018

Contributor

@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?

Contributor

duglin commented Jun 8, 2018

@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?

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Jun 8, 2018

Contributor

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?

Contributor

caniszczyk commented Jun 8, 2018

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?

@sclevine

This comment has been minimized.

Show comment
Hide comment
@sclevine

sclevine Jun 9, 2018

@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.

sclevine commented Jun 9, 2018

@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.

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Jun 9, 2018

Contributor
Contributor

duglin commented Jun 9, 2018

@garethr

This comment has been minimized.

Show comment
Hide comment
@garethr

garethr Jun 9, 2018

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

garethr commented Jun 9, 2018

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

@dankohn

This comment has been minimized.

Show comment
Hide comment
@dankohn

dankohn Jun 9, 2018

Contributor

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

Contributor

dankohn commented Jun 9, 2018

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

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Jun 11, 2018

Contributor

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

Contributor

caniszczyk commented Jun 11, 2018

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

@chipchilders

This comment has been minimized.

Show comment
Hide comment
@chipchilders

chipchilders Jun 12, 2018

@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.

chipchilders commented Jun 12, 2018

@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.

@dankohn

This comment has been minimized.

Show comment
Hide comment
@dankohn

dankohn Jun 12, 2018

Contributor
Contributor

dankohn commented Jun 12, 2018

@sclevine

This comment has been minimized.

Show comment
Hide comment
@sclevine

sclevine Jun 13, 2018

@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.

sclevine commented Jun 13, 2018

@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.

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Jun 15, 2018

Contributor

scheduled to present Aug 21st at 8am PT

Contributor

caniszczyk commented Jun 15, 2018

scheduled to present Aug 21st at 8am PT

@caniszczyk caniszczyk closed this Jun 15, 2018

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Aug 28, 2018

Contributor

@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?

Contributor

caniszczyk commented Aug 28, 2018

@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?

@sclevine

This comment has been minimized.

Show comment
Hide comment
@sclevine

sclevine Aug 28, 2018

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.

sclevine commented Aug 28, 2018

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.

@sclevine

This comment has been minimized.

Show comment
Hide comment
@sclevine

sclevine commented Aug 31, 2018

@caniszczyk proposed here: #150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment