Date
1 - 7 of 7
Staging and Runtime Hooks Feature Narrative
|
Troy Topnik
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.
https://docs.google.com/document/d/1PnTtTLwXOTG7f70ilWGlbTbi1LAXZu9zYnrUVvjr31I/edit 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 Cloud Foundry. 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: https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle/pull/13 Please weigh in with comments in the document itself or in this thread. Thanks, TT |
|
|
|
Mike Youngstrom <youngm@...>
An interesting proposal. Any thoughts about this proposal in relation to
toggle quoted message
Show quoted text
multi-buildpacks [0]? 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 multi-bulidpack). This feature also appears to be somewhat related to [1]. I hope that someone is overseeing all these newly proposed buildpack features to help ensure they are coherent. Mike [0] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/H64GGU6Z75CZDXNWC7CKUX64JNPARU6Y/ [1] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/GRKFQ2UOQL7APRN6OTGET5HTOJZ7DHRQ/#SEA2RWDCAURSVPIMBXXJMWN7JYFQICL3 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 |
|
|
|
John Shahid
Hi Troy,
toggle quoted message
Show quoted text
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. Cheers, JS 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 |
|
|
|
Troy Topnik
Credit to Jan Dubois, who actually drafted the document, and who will be helping me respond to your comments in the document.
I'll provide concrete use cases where possible. The ones I have immediately to hand are specific to Stackato which implements this feature a little differently and in some cases rely on features not available in CF (e.g. OS package installs). I'll try to generalize the examples, or at least explain how they would be relevant to core CF. TT |
|
|
|
Troy Topnik
I think many of the use cases *could* be dealt with by multi-buildpack support or in a forked buildpack which executes the desired commands. However, the point of the feature is to allow the addition of these commands to the staging process without having to create an additional buildpack or make modifications to an existing one.
In my experience, users who know the application framework they work with may not be that familiar with the buildpacks that deploy them (e.g. Java developers trying to figure out the Ruby code in the Java buildpack). This allows them to make small "one off" modifications for a particular application deployment. TT |
|
|
|
Ted Young
Hi Troy,
toggle quoted message
Show 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 solutions. Thanks, Ted On Tue, Apr 12, 2016 at 8:14 PM, John Shahid <jshahid(a)pivotal.io> wrote:
Hi Troy, |
|
|
|
Troy Topnik
I think if we can get some consensus on the .profile script support (AKA Runtime Hooks), we should move forward with that. Jan has already separated that work into a separate PR, so it could be merged independently.
https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle/pull/14 For the staging hooks, we can potentially implement the proposed functionality in pre-staging and post-staging *buildpacks* in conjunction with the multi-buildpacks support Mike mentions above. This is a little more work for the user, but avoids the need to expand the Heroku buildpack contract. I'm not totally convinced that the original proposal actually breaks buildpack compatibility, but moving staging hooks into their own auxiliary buildpacks should remove any remaining points of contention and would not require any merges into buildpack_app_lifecycle. I think you've convinced me (separate discussion) that things like db initialization are best done in Tasks. TT |
|
|