On Thu, May 12, 2016 at 12:52 PM, Danny Rosen <drosen(a)pivotal.io> wrote:

Fair enough. Though if you divorce the binary from the buildpack you
greatly increase the complexity of the environment.

I respectfully disagree. Build pack binaries are nothing more than
packages (just a different format than rpm or deb). Any competent Linux
administrator should be familiar with package management for their distro
of choice, and that includes the ability to have an internal repo (i.e.
mirror) for the distro's packages. Essentially the idea here would be to
do the same thing but for build pack binaries. Because having internal
repos / mirrors is something a lot of large companies do, I suspect many
administrators will be familiar with these concepts.

I think this change could actually simplify build packs. Currently most of
the build packs have ugly hacks in them to intercept requests for external
files, translate URLs and load local copies of files instead [1]. The idea
that I'm proposing would simply require the build packs to pull files from
a repo. It doesn't matter if you are behind a firewall or on the public
Internet. You just download the files from a configured repository.
Simple and straightforward.

[1] -
https://github.com/cloudfoundry/compile-extensions/tree/9932bb1d352b88883d76df41e797a6fa556844f0#download_dependency

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

Again, I disagree. I don't think you can address them using the current
architecture because it's the architecture that's the problem. Bundling
binaries with the build packs is at it's core a bad idea. Mike D listed
some of these earlier in this email thread. Summarizing the ones that come
to mind below.

- large build packs are hard to distribute
- large build packs increase staging time and in some cases cause staging
failures
- build packs are tied to the stack of the binaries they include
- build packs are tied to specific versions of the binaries they include
- supporting multiple sets of binaries requires multiple build packs or
really large build packs
- customizing build packs becomes more difficult as you now have to wrap
up the binaries in your custom build pack
- build packs are forced to release to keep up with their binaries, not
because the build packs need to change at that pace

Separating the binaries and build packs would seem to address these
issues. It would also turn binary management into a task that is more
similar to what Linux admins do today for their distro's packages. Perhaps
we could even piggy back on existing tools in this space to manage the
binaries like Artifactory.

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

This is an over simplification and only partially addresses one issue with

bundling binaries into the build pack. The original issue on this thread
is being able to support the addition of a new stack. Mike D made the
point that supporting an additional stack would be difficult because it
would cause the size of the build pack to spike. He offered one possible
solution, but that looked like it would require work to the cloud
controller. I offered the idea of splitting the binaries out of the build
pack. It doesn't require any cloud controller work and it would scale
nicely as additional stacks are added (assuming you have an HTTP server
with a large enough disk).

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.

I think that could be helpful. I remember back to the early days of Diego
when it could pull in a zip archive and it was nice in certain situations.
Having said that, I'm not seeing how this would help with the other issues
caused by having build packs and binaries bundled together. In particular,
the one of supporting multiple stacks.

Dan


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)pivotal.io>
wrote:

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

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

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.

Dan

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
<http://docs.cloudfoundry.org/buildpacks/proxy-usage.html> that would
allow custom buildpacks to be deployed
<http://docs.cloudfoundry.org/buildpacks/custom.html#deploying-with-custom-buildpacks>
with an app.

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

See responses inline:

On Thu, May 12, 2016 at 9:04 AM, Danny Rosen <drosen(a)pivotal.io> 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

restrictive.
-- 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:
https://github.com/cloudfoundry/compile-extensions/issues/7 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

Mike