Ok, I added to the PR a README.md with (1) instructions for writing a plugin (2) instructions for finding the examples and information about them, and (3) a glossary with definitions of terms used in the readme:
https://github.com/apache/trafficcontrol/pull/2513/commits/a9b927c6b6551696b6049442a2632777eace32d8 And a proxy plugin, which can be used to reverse proxy to "microservices' if someone wants to: https://github.com/apache/trafficcontrol/pull/2513/commits/17d885275ed42cb206ba11de3a2002fb371a2229 >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? The way Grove handles that, which I also put in this README, is by recommending people prefix plugins with either their organization name, or a GUID. The plugin interface shouldn't ever have hooks or variables removed; but if it does, we should be able to follow the usual deprecate-then-remove cycle. >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? I honestly don't think that's necessary, I can't imagine any of the existing data or hooks being removed, and it simply wasn't a problem in Grove or the Monitor. We just added hook functions and data as we needed them. We can always add more detailed documentation, and more plugins, later. This is just the initial system. We really need something, there are endpoints in Perl we can't rewrite in Go until we have this (or something else, if people aren't happy with this system). On Mon, Oct 1, 2018 at 2:19 PM Chris Lemmons <alfic...@gmail.com> wrote: > It looks like the latest commits just added the README. It looks much > better; the README really clarifies how it should work. > > I'm not sure exactly what a "plugin version" should do. It seems > reasonably expectable that it will follow the same compatibility as > the rest of the project. That is, it only breaks on major version > revs. Minor versions might add hooks, though. It'd be nice if plugins > could request the current version, in case they want to manage > compatibility manually. But I suspect most won't bother, preferring to > just keep it all up-to-date instead. I don't think the lack of a > version api is a blocker, though. > > Are there any other thoughts? This is a few months old now and might > could stand merging soon. > On Mon, Oct 1, 2018 at 11:57 AM Eric Friedrich (efriedri) > <efrie...@cisco.com.invalid> wrote: > > > > I think some documentation/definitions would be great here as well. > > > > Whats a TO extension vs hook vs data? Are there any examples of how they > could be used? > > > > —Eric > > > > > > > On Oct 1, 2018, at 1:44 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > > > > > > 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 <r...@apache.org> 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, > > >
