Can we get a concise README.md on how to create a custom TO plugin that also links to the examples you've included in the PR? Also as new hooks are added, I think we'll need documentation for every hook to describe where in the request flow the hooks are called and the data available to each hook.
Maybe since we're discussing a microservice plugin, you could lay out the basic high-level steps required to implement that in this plugin framework (not necessarily down to the nitty gritty details). Also, there's the question of the plugin interface versioning. How will we be versioning the plugin interface with guarantees to not break any plugins outside of our repo? Should we start out by tagging this plugin framework as experimental so that we don't really provide any compatibility guarantees while we're still working out the kinks? - Rawlin On Mon, Oct 1, 2018 at 10:38 AM Robert Butts <[email protected]> wrote: > > So, as we move Traffic Ops from Perl to Go, we need a way to write > extensions in Go, like we have in Perl. > > I wrote a plugin system for Go, modeled after the plugin frameworks in > Grove and Traffic Monitor, PR is here: > > https://github.com/apache/trafficcontrol/pull/2513 > > It's by no means complete, just like with Grove, we'll have to add > additional hooks and data as we find the need. But it works, it has basic > hooks, and includes some sample plugins. > > There was a question about microservices, if someone wants to write > extensions to their Traffic Ops as separate services, instead of built into > the same app. This framework allows that, it's easy to make a plugin that > calls out to another service when an endpoint is requested. > > Does anyone object to this PR? Could I get some +1's/-1's so we can get a > feel for whether people are OK with this PR being merged, and using this > plugin system for Traffic Ops going forward? > > Thanks,
