Re: Binary Service Broker Feature Narrative
Mike Youngstrom <youngm@...>
The main concerns I have is:toggle quoted message Show quoted text
* Maintaining Compatibility:
If a buildpack were to make a breaking change it may be complex to know
that a vendor must upgrade its integration before the user can upgrade the
buildpack in an environment. It seems this would require the buildpack to
publish and maintain API like compatibility with whatever hooks the
buildpack believes broker vendors will need to help ensure compatibility.
I'm not convinced that simply telling the vendors to put a script into
profile.d and/or having the buildpack execute a script during staging will
be enough of an API to protect the vendor, buildpack developer, and user
from the potential breakages.
* Integration customization:
One of the nice things about buildpacks is the very clear customization
path. We use app dynamics and we have custom requirements for how app
dynamics should be configured that app dynamics won't want to support.
What would the story be for customizing the app dynamics broker's code that
gets injected? It would be nice if there were a simple and consistent
mechanism in place similar to what buildpacks already provide.
* Services without brokers:
A number of these services (especially initially) may not have official
brokers installed for every customer. These customers instead tend to use
user provided services. Would these customers now be required to create
brokers? Not a big problem for me but I'm pretty sure that today user
provided services are quite common.
* Other extension requirements opportunity missed?
By making this solution service broker specific are we missing an
opportunity to solve a broader buildpack extension problem? Today we have
users that occasionally require additional native library dependencies not
available in the rootfs and not related to a service. These situations
often require the user to fork the buildpack or instead look forward to
docker. It seems the requirements for broker extensions and these
non-broker extensions often look functionally similar. Perhaps some effort
could be put toward a more general extension mechanism for buildpacks that
could work for both broker and non broker use cases? Just a thought.
I'm not sure what the best solution is. Submitting PRs into buildpacks
doesn't seem like that bad of an approach to me. This is how the Linux
Kernal works afterall. :) That said, I'm inclined to think that this
effort could be focused on solving first the problem of binary distribution
and see how things go from there.
On Wed, Apr 6, 2016 at 9:04 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: