Re: Binary Service Broker Feature Narrative
Mike Dalessio
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.
toggle quoted message
Show quoted text
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#