Traffic Ops Extensions in Go

[Robert Butts <ro...@apache.org>]

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,

Re: Traffic Ops Extensions in Go

[Dewayne Richardson <de...@apache.org>]

I like the idea of the "microservice_plugin" because really what you are
describing is true "Proxy" functionality.  So maybe that's what we are
looking for, is a "Proxy" config that allows for remote URL's.

-Dew

On Mon, Oct 1, 2018 at 11:04 AM Robert Butts <ro...@apache.org> wrote:

> Yeah, we could write a framework like that. But this framework is strictly
> more powerful than that. Would you want both? Seems simpler to just have
> one plugin framework that can do both.
>
> In fact, if you wanted, you could add a generic "microservice plugin" as a
> plugin, which looks at the config file for mappings like that, e.g.
> `"microservice_plugin":{ ["/api/1.3/myawesomeextensiton", "
> http://myushost.com/mypath"] }`, and remaps anything.
>
>
> On Mon, Oct 1, 2018 at 10:54 AM Jan van Doorn <jv...@knutsel.com> wrote:
>
> > Yea, I don’t mean edit the routes.go to add your service and compile it
> > in, but make it so that you can have a dynamic list of
> >
> > Path -> absolute URL
> >
> > So for example
> >
> > /api/1.3/myawesomeextensiton http://myushost.com/mypath <
> > http://myushost.com/mypath>
> >
> > Would result in that path calling that absolute URL.
> >
> > Would that not work?
> >
> > Cheers,
> > JvD
> >
> > > On Oct 1, 2018, at 09:50, Robert Butts <ro...@apache.org> wrote:
> > >
> > > @jan this is for extensions, for code an organization isn't able to
> open
> > > source.
> > >
> > > Sure, you could just add a line to `routes.go` if you want. You can do
> > that
> > > right now. But you'd have to deal with regular merge conflicts.
> > >
> > > With this dedicated plugin system, the plugins are self-contained, you
> > > don't modify any other file to create your plugin. Which means (in
> > theory)
> > > you should never have merge conflicts when Traffic Control changes.
> > >
> > >
> > > On Mon, Oct 1, 2018 at 10:44 AM Jan van Doorn <jv...@knutsel.com> wrote:
> > >
> > >> Why wouldn’t we just have the routes.go be able to point to an
> “outside
> > >> url” that is the micro service?
> > >>
> > >> Rgds,
> > >> JvD
> > >>
> > >>
> > >>> On Oct 1, 2018, at 09:39, Robert Butts <ro...@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,
> > >>
> > >>
> >
> >
>

Re: Traffic Ops Extensions in Go

[Robert Butts <ro...@apache.org>]

Yeah, we could write a framework like that. But this framework is strictly
more powerful than that. Would you want both? Seems simpler to just have
one plugin framework that can do both.

In fact, if you wanted, you could add a generic "microservice plugin" as a
plugin, which looks at the config file for mappings like that, e.g.
`"microservice_plugin":{ ["/api/1.3/myawesomeextensiton", "
http://myushost.com/mypath"] }`, and remaps anything.


On Mon, Oct 1, 2018 at 10:54 AM Jan van Doorn <jv...@knutsel.com> wrote:

> Yea, I don’t mean edit the routes.go to add your service and compile it
> in, but make it so that you can have a dynamic list of
>
> Path -> absolute URL
>
> So for example
>
> /api/1.3/myawesomeextensiton http://myushost.com/mypath <
> http://myushost.com/mypath>
>
> Would result in that path calling that absolute URL.
>
> Would that not work?
>
> Cheers,
> JvD
>
> > On Oct 1, 2018, at 09:50, Robert Butts <ro...@apache.org> wrote:
> >
> > @jan this is for extensions, for code an organization isn't able to open
> > source.
> >
> > Sure, you could just add a line to `routes.go` if you want. You can do
> that
> > right now. But you'd have to deal with regular merge conflicts.
> >
> > With this dedicated plugin system, the plugins are self-contained, you
> > don't modify any other file to create your plugin. Which means (in
> theory)
> > you should never have merge conflicts when Traffic Control changes.
> >
> >
> > On Mon, Oct 1, 2018 at 10:44 AM Jan van Doorn <jv...@knutsel.com> wrote:
> >
> >> Why wouldn’t we just have the routes.go be able to point to an “outside
> >> url” that is the micro service?
> >>
> >> Rgds,
> >> JvD
> >>
> >>
> >>> On Oct 1, 2018, at 09:39, Robert Butts <ro...@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,
> >>
> >>
>
>

Re: Traffic Ops Extensions in Go

[Jan van Doorn <jv...@knutsel.com>]

Yea, I don’t mean edit the routes.go to add your service and compile it in, but make it so that you can have a dynamic list of

Path -> absolute URL

So for example

/api/1.3/myawesomeextensiton http://myushost.com/mypath <http://myushost.com/mypath>

Would result in that path calling that absolute URL.

Would that not work? 

Cheers,
JvD

> On Oct 1, 2018, at 09:50, Robert Butts <ro...@apache.org> wrote:
> 
> @jan this is for extensions, for code an organization isn't able to open
> source.
> 
> Sure, you could just add a line to `routes.go` if you want. You can do that
> right now. But you'd have to deal with regular merge conflicts.
> 
> With this dedicated plugin system, the plugins are self-contained, you
> don't modify any other file to create your plugin. Which means (in theory)
> you should never have merge conflicts when Traffic Control changes.
> 
> 
> On Mon, Oct 1, 2018 at 10:44 AM Jan van Doorn <jv...@knutsel.com> wrote:
> 
>> Why wouldn’t we just have the routes.go be able to point to an “outside
>> url” that is the micro service?
>> 
>> Rgds,
>> JvD
>> 
>> 
>>> On Oct 1, 2018, at 09:39, Robert Butts <ro...@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,
>> 
>> 

Re: Traffic Ops Extensions in Go

[Robert Butts <ro...@apache.org>]

@jan this is for extensions, for code an organization isn't able to open
source.

Sure, you could just add a line to `routes.go` if you want. You can do that
right now. But you'd have to deal with regular merge conflicts.

With this dedicated plugin system, the plugins are self-contained, you
don't modify any other file to create your plugin. Which means (in theory)
you should never have merge conflicts when Traffic Control changes.


On Mon, Oct 1, 2018 at 10:44 AM Jan van Doorn <jv...@knutsel.com> wrote:

> Why wouldn’t we just have the routes.go be able to point to an “outside
> url” that is the micro service?
>
> Rgds,
> JvD
>
>
> > On Oct 1, 2018, at 09:39, Robert Butts <ro...@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,
>
>

Re: Traffic Ops Extensions in Go

[Jan van Doorn <jv...@knutsel.com>]

Why wouldn’t we just have the routes.go be able to point to an “outside url” that is the micro service?

Rgds,
JvD


> On Oct 1, 2018, at 09:39, Robert Butts <ro...@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,

Re: Traffic Ops Extensions in Go

[Dewayne Richardson <de...@apache.org>]

I've been reviewing the PR and wanted to get community feedback.  It looks
like this feedback was very valuable by improving the docs and the
versioning.

+1

-Dew

On Mon, Oct 1, 2018 at 3:55 PM Rawlin Peters <ra...@gmail.com>
wrote:

> On Mon, Oct 1, 2018 at 2:35 PM Robert Butts <ro...@apache.org> wrote:
> >
> > >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.
>
> Sounds good, I just wanted to make sure plugin compatibility was
> considered, and it sounds like it has been. I don't really have any
> other thoughts or concerns now that there's some initial documentation
> and even the microservice example. Thanks!
>

Re: Traffic Ops Extensions in Go

[Rawlin Peters <ra...@gmail.com>]

On Mon, Oct 1, 2018 at 2:35 PM Robert Butts <ro...@apache.org> wrote:
>
> >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.

Sounds good, I just wanted to make sure plugin compatibility was
considered, and it sounds like it has been. I don't really have any
other thoughts or concerns now that there's some initial documentation
and even the microservice example. Thanks!

Re: Traffic Ops Extensions in Go

[Robert Butts <ro...@apache.org>]

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 <al...@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)
> <ef...@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 <ra...@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 <ro...@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,
> >
>

Re: Traffic Ops Extensions in Go

[Chris Lemmons <al...@gmail.com>]

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)
<ef...@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 <ra...@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 <ro...@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,
>

Re: Traffic Ops Extensions in Go

["Eric Friedrich (efriedri)" <ef...@cisco.com.INVALID>]

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 <ra...@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 <ro...@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,

Re: Traffic Ops Extensions in Go

[Rawlin Peters <ra...@gmail.com>]

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 <ro...@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,