Date
1 - 10 of 10
Proposal for supporting the application of multiple buildpacks to a CF app
Stephen Levine
Hi All,
The CF Buildpacks team and CAPI team are planning a coordinated effort to introduce support for applying multiple buildpacks during CF application staging. We would like to welcome any and all comments on our proposal[1] from the community before we begin this effort in a few weeks. A PDF is attached for those who have issues with Google Docs. Thanks! Stephen Levine CF Buildpacks PM [1] https://docs.google.com/document/d/1YEzw_g1MRBzEOhSGNPVLHpyf2BGHqFITy38fsDnDBfI/edit?usp=sharing |
|
Mike Youngstrom <youngm@...>
I love it! I can also see how this feature will pair nicely with process
toggle quoted message
Show quoted text
types support in v3. Nice proposal! Mike On Tue, Nov 1, 2016 at 9:54 AM, Stephen Levine <slevine(a)pivotal.io> wrote:
Hi All, |
|
Daniel Mikusa
+1 - Can't wait. This looks like it will be a nice step forward for build
toggle quoted message
Show quoted text
packs! Dan On Tue, Nov 1, 2016 at 1:38 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:
I love it! I can also see how this feature will pair nicely with process |
|
Roche, Brian <Brian.Roche@...>
This is super cool!
toggle quoted message
Show quoted text
Thanks Brian ___________________________ Brian Roche Senior Director of Software Engineering Dell EMC | Cloud Platform Team mobile 781 727 7337 follow me @BrianRocheBos Brian.Roche(a)Dell.com 145 Broadway, Cambridge, Massachusetts, 02142 From: Daniel Mikusa <dmikusa(a)pivotal.io> Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: Tuesday, November 1, 2016 at 5:37 PM To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: [cf-dev] Re: Re: Proposal for supporting the application of multiple buildpacks to a CF app +1 - Can't wait. This looks like it will be a nice step forward for build packs! Dan On Tue, Nov 1, 2016 at 1:38 PM, Mike Youngstrom <youngm(a)gmail.com<mailto:youngm(a)gmail.com>> wrote:
I love it! I can also see how this feature will pair nicely with process types support in v3. Nice proposal! Mike On Tue, Nov 1, 2016 at 9:54 AM, Stephen Levine <slevine(a)pivotal.io<mailto:slevine(a)pivotal.io>> wrote: Hi All, The CF Buildpacks team and CAPI team are planning a coordinated effort to introduce support for applying multiple buildpacks during CF application staging. We would like to welcome any and all comments on our proposal[1] from the community before we begin this effort in a few weeks. A PDF is attached for those who have issues with Google Docs. Thanks! Stephen Levine CF Buildpacks PM [1] https://docs.google.com/document/d/1YEzw_g1MRBzEOhSGNPVLHpyf2BGHqFITy38fsDnDBfI/edit?usp=sharing |
|
Stephen Levine
+ Pivotal PMs/Anchors for visibility
toggle quoted message
Show quoted text
On Tue, Nov 1, 2016 at 11:54 AM, Stephen Levine <slevine(a)pivotal.io> wrote:
Hi All, |
|
John Liptak
I don't see any consideration in the document for having multiple start
toggle quoted message
Show quoted text
commands and picking who gets the default PORT. On Wed, Nov 2, 2016 at 1:37 PM Stephen Levine <slevine(a)pivotal.io> wrote:
+ Pivotal PMs/Anchors for visibility |
|
Dubois, Jan <jan.dubois@...>
That is indeed true. All the use cases still assume a single main application process, and therefore a single start command, and owner of $PORT. Any additional processes are meant as helpers inside the container only (either short-lived subprocesses, or long-running sidecars).
toggle quoted message
Show quoted text
If multiple app processes are required, is there a reason not to run them in separate containers? Cheers, -Jan From: John Liptak <john.h.liptak(a)gmail.com> Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: Thursday, November 3, 2016 at 12:51 To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: [cf-dev] Re: Re: Proposal for supporting the application of multiple buildpacks to a CF app I don't see any consideration in the document for having multiple start commands and picking who gets the default PORT. On Wed, Nov 2, 2016 at 1:37 PM Stephen Levine <slevine(a)pivotal.io<mailto:slevine(a)pivotal.io>> wrote:
+ Pivotal PMs/Anchors for visibility On Tue, Nov 1, 2016 at 11:54 AM, Stephen Levine <slevine(a)pivotal.io<mailto:slevine(a)pivotal.io>> wrote: Hi All, The CF Buildpacks team and CAPI team are planning a coordinated effort to introduce support for applying multiple buildpacks during CF application staging. We would like to welcome any and all comments on our proposal[1] from the community before we begin this effort in a few weeks. A PDF is attached for those who have issues with Google Docs. Thanks! Stephen Levine CF Buildpacks PM [1] https://docs.google.com/document/d/1YEzw_g1MRBzEOhSGNPVLHpyf2BGHqFITy38fsDnDBfI/edit?usp=sharing |
|
John Liptak
Even with that limitation, which buildpack is supposed to create the start
toggle quoted message
Show quoted text
command? I could see instances where the "normal" buildpack start command is fine but also cases where the add on would want to create it. On Thu, Nov 3, 2016 at 6:32 PM Dubois, Jan <jan.dubois(a)hpe.com> wrote:
That is indeed true. All the use cases still assume a single main |
|
Daniel Mikusa
I believe the idea is that the last build pack in the list will have the
final say. It can either return the command it wants to use or it can take the command from a previous build pack and use (or possibly modify and use) that instead. Basically all build pack's have the option to return a command, but any build pack that runs after in the chain can override that command. Last one wins. Dan On Fri, Nov 4, 2016 at 10:45 AM, John Liptak <john.h.liptak(a)gmail.com> wrote: Even with that limitation, which buildpack is supposed to create the start |
|
Mike Youngstrom <youngm@...>
Interesting. I assumed that you would be able to create multiple process
toggle quoted message
Show quoted text
types with the multiple buildpacks. I understand you can only have one named "web" but I thought that if each buildpack returned a different named process then they would all get merged together and create multiple process types. It makes sense that the last buildpack should be able to decide that. The question is what will the default behavior be of the provided buildpacks when they are the last one if buildpacks before release processes that don't conflict with its process? Mike On Fri, Nov 4, 2016 at 9:10 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
I believe the idea is that the last build pack in the list will have the |
|