1. Cf-Dev
  2. Messages

Re: Binary Service Broker Feature Narrative

Mike Youngstrom <youngm@...>
 

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.

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


Mike

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

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)gmail.com> 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
platforms.

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.

Thoughts?

Mike

On Tue, Apr 5, 2016 at 12:15 PM, Danny Rosen <drosen(a)pivotal.io> 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] -
https://docs.google.com/document/d/145aOpNoq7BpuB3VOzUIDh-HBx0l3v4NHLYfW8xt2zK0/edit#

attachment.html

attachment.html

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.