Date
1 - 7 of 7
Binary Service Broker Feature Narrative
|
Danny Rosen
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# |
|
|
|
Mike Youngstrom <youngm@...>
An interesting idea. I see the licensing of agent binaries and upgrading
toggle quoted message
Show quoted text
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, |
|
|
|
Mike Dalessio
Hi Mike,
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 |
|
|
|
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. Mike On Wed, Apr 6, 2016 at 9:04 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Hi Mike, |
|
|
|
Mike Dalessio
Responses inline ...
On Wed, Apr 6, 2016 at 12:55 PM, Mike Youngstrom <youngm(a)gmail.com> wrote: The main concerns I have is: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: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 conversation. 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 products. 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, obviously. 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. Without going into too much painful detail, there are compelling legal, support, and staffing reasons for why PRs for commercial products aren't sustainable. 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 team. 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. -mike
|
|
|
|
Mike Youngstrom <youngm@...>
Thanks for the responses Mike. See inline:
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 yourAdding thirdparty agents to the CI pipeline will help. But, if there is ever a breaking change in a buildpack we now have a loose dependency on the thirdparty broker being upgraded before I can potentially upgrade to a new cf-release. It is that kind of loose dependency breakage that I'm more concerned about. I'd like to explore whether we can meet agent requirements with profile.dPerhaps the buildpack lifecycle hooks you mention will be good enough of an api. Do you have anything describing the makeup of these hooks? * Integration customization:Here is our use case. App Dynamics designates an application with aOne of the nice things about buildpacks is the very clear customizationThis isn't a use case we considered. Can you help me understand what kinds location in its UI using an App Name, Tier Name, and Node Name. Our organization has placed specific standard naming conventions around what specifically the App Name and Tier Name should be. My organization also uses ServiceNow for CI management. The App Dynamics naming standard is to use specific field in the application's CI for App Name and Tier Name. We only allow applications to use app dynamics if they have a service now service bound and we configure their App Name and Tier Name with values from the service now service's credentials. That is an example. If you think other use cases should be prioritized, then maybe we can have that conversation with Danny.I wasn't suggesting that you move focus off of this problem area and towards something else. I was just pointing out that there may be an opportunity here to kill 2 birds with one stone if we look a little broader, since the problem appears similar to me. You guys are the experts but let me brain storm a little here to perhaps help the discussion along. This proposal already introduces the new concept of some kind of "buildpack hook" contract. What if you made it possible for users to specify buildpack hooks an needs in addition to the buildpack as part of the application model? (Lowest common denominator this could be an Environment Variable) Then also allow service brokers to supply the same type of hook via VCAP_SERVICES (as this proposal proposes). It would be nice if broker hooks could be overridden by application configured hooks to cover odd use cases. Thoughts? Agent components may not be open-source (or OSS-compatible with APL2.0), and may not be licensed for general redistribution by Foundation vendors.I agree this is an issue. Does the binary redistribution aspect of the proposal cover this concern? Or are there also legal issues with code that might go into a buildpack to configure these non ASL compatible agents? Thanks for taking the time to work this through with me. Mike |
|
|
|
Danny Rosen
Following up on this thread, we plan on spending some time this week to
toggle quoted message
Show quoted text
discuss the functionality of the Binary Service Broker. If you have any additional feedback regarding the project we urge you to comment on the feature narrative [1 <https://docs.google.com/document/d/145aOpNoq7BpuB3VOzUIDh-HBx0l3v4NHLYfW8xt2zK0/edit?usp=gmail> ] [1] - https://docs.google.com/document/d/145aOpNoq7BpuB3VOzUIDh-HBx0l3v4NHLYfW8xt2zK0/edit?usp=gmail On Wed, Apr 6, 2016 at 4:07 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:
Thanks for the responses Mike. See inline: |
|
|