I am +1 on this idea. On Fri, Nov 1, 2019 at 09:26 Gray, Jonathan <[email protected]> wrote:
> The available routes and what associated backend they go to are operator+ > sensitive information. I'd also lean towards a stronger degree of safety > and only make it read-only. > > Jonathan G > > On 11/1/19, 8:41 AM, "Hoppal, Michael" <[email protected]> > wrote: > > I would be +1 on TO API routing blacklist. > > I think it is a great idea to allow us to continue to move fast while > minimizing risk. > > I do agree we should expose the current state of the blacklist as an > API endpoint as to easily get insight into the current configuration. We > could even make the blacklist driven by the API instead of a JSON config > file. > > Michael > > On 10/31/19, 4:18 PM, "Gray, Jonathan" <[email protected]> > wrote: > > Not trying to sideswipe, but could we expose that as an endpoint > with a Golang list as well to solve: > https://protect2.fireeye.com/url?k=1978833f-459c8df4-1978a48b-000babff3540-c717b11942d8382e&u=https://github.com/apache/trafficcontrol/issues/2872 > > Jonathan G > > On 10/31/19, 3:51 PM, "Rawlin Peters" <[email protected]> wrote: > > Hey all, > > We've been picking up momentum in the TO Perl -> Go rewrite > recently, > which has gotten me thinking of ways to reduce the risk of > possible > regressions in the rewritten APIs. I'd like to propose that we > implement a sort of "routing blacklist" for the TO API routes. > > At a high level, this blacklist would be a simple JSON config > file like this: > { > "perlRoutes": [ > {"method": "GET", "path": "/api/1.1/foos"}, > {"method": "POST", "path": "/api/1.1/foos"} > ], > "disabledRoutes": [ > {"method": "GET", "path": "/api/1.1/foos"}, > {"method": "POST", "path": "/api/1.1/foos"} > ] > } > > APIs in "perlRoutes" would be explicitly routed to the Perl, > even if > the Go route exists and could handle the request. The primary > use case > for this feature would be to deploy an upgraded version of > TO-Go with > rewritten APIs without having TO-Go handle the requests yet. > Post-upgrade, you could remove a rewritten route from the > blacklist on > a single TO instance, validate it for some period of time, > then roll > out the rewritten API to other TO instances by removing the > API from > their blacklists. > > APIs in "disabledRoutes" would be explicitly disabled. The use > cases > for this field would include: > - disabling endpoints that are part of an incomplete feature > and don't > really make sense to use on their own yet > - disabling endpoints that have known, serious issues that > should be > disabled immediately > This would make it easier to plug holes in TO without having to > rebuild and redeploy. > > Ideally, this config file would be SIGHUP-able so that it can > be > reconfigured without having to restart TO. Also, there should > be a > hardcoded list of "Perl-routable" routes within TO-Go, so that > you > can't just depend on Perl forever if you wanted. I would > propose that > newly rewritten routes be added to this hardcoded list in > TO-Go. Then > after being in one release as "Perl-routable", they would > become > "non-Perl-routable" in the following release. > > IMO we could've used something like this since the beginning > of the TO > Perl -> Go rewrite effort, but we still do have a decent > amount of > routes left that this could be useful for. > > Please let me know what you think. If we're generally +1 on > this idea, > I'll throw together a blueprint with more details, then maybe > I can > convince my boss to let me work on it ;) > > - Rawlin > > > > > > >
