toggle quoted messageShow quoted text
I agree that we should bring our buildpack implementation up to date with
Heroku's by adding the .profile runtime hook. Also, I believe Eric Malm had
some thoughts on this hook, and how we could use something like it to make
application start be aware of when an app was in "pre-flight" and delay
starting the health monitor.
However, I am concerned about adding the staging hooks. In particular, what
is being proposed is that we fork the buildpack workflow from Heroku. That
sounds like a pretty big public maneuver, as it could make our buildpacks
no longer compatible with Heroku's. I would suggest we not fork the
buildpack model, and instead consult with Heroku about improving it.
The primary given reason for staging hooks is not that this feature is
necessary for Cloud Foundry users, but that it will help with demos. In
general, I do not think we should make large changes just to help with
demos, there must be broader utility that is commensurate with the size of
the change. I understand you have found utility with these hooks as a
useful shim, and users would like to shim things as well. However, some of
the use cases mentioned for staging hooks look like issues that are not
specific to staging (database migrations, etc) but are instead "camping" on
staging as a convenience. Buildpack staging is very specific to a single
operating system (linux), and a single deployment style (docker apps cannot
use these features). For issues that are not specific to buildpacks, I
would prefer we deliver higher-level, cross-platform solutions.
My suggestion is to unpack the staging issues you raise, and separate out
the issues that are specific to buildpacks. For those issues, we open a
discussion with Heroku. For more general issues, we look for cf-wide
On Tue, Apr 12, 2016 at 8:14 PM, John Shahid <jshahid(a)pivotal.io> wrote:
Thanks for putting together this proposal. I added some comments/questions
to the document. I would love your feedback/response on those. Most of the
comments are concerned with the lack of concrete use cases. I think adding
a few examples to each use case will clarify the value added by the hooks.
On Mon, Apr 11, 2016 at 1:04 PM Mike Youngstrom <youngm(a)gmail.com> wrote:
An interesting proposal. Any thoughts about this proposal in relation to
multi-buildpacks ? How many of the use cases for this feature go away
in lue of multi-buildpack support? I think it would be interesting to be
able to apply hooks without checking scripts into application (like
This feature also appears to be somewhat related to . I hope that
someone is overseeing all these newly proposed buildpack features to help
ensure they are coherent.
On Fri, Apr 8, 2016 at 4:16 PM, Troy Topnik <troy.topnik(a)hpe.com> wrote:
This feature allows developers more control of the staging and
deployment of their application code, without them having to fork existing
buildpacks or create their own.
Hooks give developers the ability to optionally:
* run scripts in the staging container before and/or after the
bin/compile scripts executed by the buildpack, and
* run scripts in each app container before the app starts (via .profile
as per the Heroku buildpack API)
A similar feature has been available and used extensively in Stackato
for a few years, and we'd like to contribute this functionality back to
A proof-of-concept of this feature has already been submitted as a pull
request, and the Feature Narrative addresses many of the questions raised
in the PR discussion:
Please weigh in with comments in the document itself or in this thread.