Re: Ubuntu Xenial stemcell and rootfs plans

Danny Rosen

Fair enough. Though if you divorce the binary from the buildpack you
greatly increase the complexity of the environment. I think we can simplify
this conversation a bit though using our *current* architecture rather than
creating new paradigms ... and more work for the buildpacks team :)

As an operator, I want my users to use custom buildpacks because the
official buildpacks (their binaries, their configuration, etc) don't suit
my needs.

- This can be achieved today! Via:
- a proxy
- an internet enabled environment
- an internal git server

One idea we're throwing around is being able to use a url containing a zip
file which could enable interesting solutions for operators who prefer the
"bring your own buildpacks but not from the internet and don't ask me to
upload it as an admin buildpack" solution.

If you're interested in working with us on this solution, let's talk! We're
happy to work with the community.

On Thu, May 12, 2016 at 12:26 PM, Daniel Mikusa <dmikusa(a)> wrote:

On Thu, May 12, 2016 at 11:59 AM, Danny Rosen <drosen(a)> wrote:

Thanks. This is helpful! I'd like get a better understanding of the

Why would an operator set their environment to be disconnected from the
internet if they wanted to enable their users to run arbitrary binaries via
a buildpack?
I don't think it wouldn't allow them to run arbitrary binaries, but it
would allow them to run arbitrary build packs. If you divorce the binaries
from the build pack, you can control the binaries separate in a corporate
IT managed, not public repository of binaries. Then users can use any
build pack they want so long as it points to the blessed internal repo of
trusted binaries.


For if an operator wanted to provide users the flexibility of executing
arbitrary binaries in buildpacks, custom buildpacks can be implemented via
an environment with internet *or* by providing a proxy
<> that would
allow custom buildpacks to be deployed
with an app.

On Thu, May 12, 2016 at 11:37 AM, Mike Youngstrom <youngm(a)>

See responses inline:

On Thu, May 12, 2016 at 9:04 AM, Danny Rosen <drosen(a)> wrote:

* One of the key value propositions of a buildpack is the lightweight
process to fork and customize a buildpack.
*The inclusion of binaries makes buildpack customization a much heavier
process and less end user friendly in a number of ways.*
-- I'm not sure I agree with this point and would like to understand
your reasoning.
I may be missing something but it was my understanding that buildpacks
with binaries included must (unless checking all binaries into git) be
added as admin buildpacks which non admin users of CF cannot do.
Therefore, if I am a simple user of cloud foundry I cannot customize a
buldpack for my one off need without involving an administrator to upload
and manage the one off buildpack. If binary dependencies were instead
managed in a way like Daniel proposes the process would simply be to fork
the buildpack and specifying that git repo when pushing. Completely self
service without admin intervention. Making it a lighter weight process.

* For some of my customers the binary inclusion policies is too
-- It's hard for me to understand this point as I do not know your
customers' requirements. Would you mind providing details so we can better
understand their needs?
I've attempted to express that need previously here: I don't
view this as a major issue but I think it could be something to consider if
buildpacks binary management is being reconsidered.

Hope those additional details help


Join { to automatically receive all group messages.