Re: Binary Service Broker Feature Narrative

Mike Dalessio

Responses inline ...

On Wed, Apr 6, 2016 at 12:55 PM, Mike Youngstrom <youngm(a)> wrote:

The main concerns I have is:

* 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.

To be clear, I think we're happy to test third-party agent in our CI
pipelines to ensure they'll continue to work. I think this addresses your
"breaking change" point in a very sustainable way.

I'd like to explore whether we can meet agent requirements with profile.d
and/or buildpack lifecycle hooks. If we find a compelling blocker, we can
revisit this and related decisions. Hopefully we can convince you as well
as agent vendors that this is a reasonable path forward.

* 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.
This isn't a use case we considered. Can you help me understand what kinds
of customizations you're making? Specifics will help drive this

* 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.
We're not proposing this as a *requirement* for vendors. Clearly, vendors
are free (though we discourage it) to provide forked buildpacks; and we're
not planning to unilaterally remove all agents from existing buildpacks.

What we *are* doing is offering ideas around a method and an API contract
for vendors who may have no other options (for legal reasons), or who
prefer to control their own release cycles (for commercial support reasons).

This proposal is an *extension* to current methods of injecting agents, not
a *replacement*; one which we feel strongly will make maintenance of
buildpacks easier for the open-source team; and which will enable (and
hopefully encourage) vendors to own and support their own commercial

* 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.
Effort *has* been put towards investigating more general extension
mechanisms. Nothing we've invented addresses every use case -- if you have
specific suggestions that we've overlooked, we're happy to discuss them,

We're choosing one particular use case and addressing it here. This use
case is timely, urgent, and commercially important for the ecosystem.

If you think other use cases should be prioritized, then maybe we can have
that conversation with Danny.

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.
Without going into too much painful detail, there are compelling legal,
support, and staffing reasons for why PRs for commercial products aren't

Agent components may not be open-source (or OSS-compatible with APL2.0),
and may not be licensed for general redistribution by Foundation vendors.
We'd like to enable those companies to participate in the CF ecosystem.

Under the current model, any work on new agents or changes to existing
agents are blocked on the small open-source Buildpacks team, and so
commercial opportunities are gated on those four or five engineers. (This
isn't a hypothetical, this is actually happening right now, and is painful
for everyone involved.)

Providing a method for companies in the CF ecosystem to unilaterally
deliver commercial functionality into the open-source core of Cloud Foundry
is critical for our collective success, and the success of the platform.
Here, we're proposing to provide a generic extension point which will allow
allocation of engineering resources where they logically should be -- on a
commercial product team, and not on an (arguably understaffed) open-source

Certainly we agree that this proposal addresses binary redistribution. I'd
like to start from that place of agreement, and learn more about the other
aspects of this proposal by attempting to implement something, before
further trying to make further decisions.



On Wed, Apr 6, 2016 at 9:04 AM, Mike Dalessio <mdalessio(a)>

Hi Mike,

You make a great point, and the question of "where should the
responsibility live" is something we debated quite a bit, and even
experimented with on a few different occasions.

You're right that, if this feature narrative is adopted, the agent broker
will own the responsibility of compatibility with each buildpack (e.g.,
php, node, java, ruby), which is not easy to do.

But the unfortunate truth is that *somebody* has to own that code, and I
don't see a compelling reason for the Buildpacks team to own and maintain
code that semantically belongs to a commercial product team; especially
when the commercial product team will likely be submitting PRs to the
individual buildpacks in any case.

Obviously there isn't a clear "this is the best way" solution, but I'd
like to understand whether there are truly compelling reasons to break
apart the agent and the agent-injection code. If there's no obvious optimal
path, then I'd prefer to keep the dependencies all contained within the
service broker to both ease maintenance and to make it clear to whom the
maintenance responsibilities belong.

On Tue, Apr 5, 2016 at 4:21 PM, Mike Youngstrom <youngm(a)> wrote:

An interesting idea. I see the licensing of agent binaries and
upgrading of agent binaries as a real problem that needs to be solved. I
like the idea of the brokers providing binary agent downloads for supported

However, I'm less comfortable asking the broker to be responsible for
scripting the installation of this agent for every possible buildpack. I'd
feel better about keeping the agent configuration logic in the buildpack.
Simply having a script run at staging or startup that sets some environment
variables or something may be enough for some platforms but the integration
may be tighter and more involved for other platforms. I'm inclined to
think that how the agent is integrated into the buildpack should remain in
the buildpack.



On Tue, Apr 5, 2016 at 12:15 PM, Danny Rosen <drosen(a)> wrote:

Hi there,
This feature narrative [1] looks to propose a new method for delivering
service-agents. This new and exciting feature would enable an ecosystem of
third-party developers to more easily create and maintain service-agents
for usage in Cloud Foundry deployments.

[1] -

Join to automatically receive all group messages.