I think adding new DS types for this makes sense because traditionally
the DS type determines the value of go_direct as well as how content
is cached (disk/ram/not cached at all). If we make the field directly
configurable on the Delivery Service, then we now have the complexity
of prohibiting
it sounds great in theory but may be easier said than done. at the very
least the route from TrafficOpsRoutes.pm should be deleted when rewritten
in Go. should the handler and all the functions used by the handler be
deleted as well? like dan said, that may be a messy effort with a high
level of
+1 on removing dead code.
IMO the danger and cost of the dead code far outweighs the benefit of the
Perl tests. Especially considering AFAIK most of the tests are just
verifying the response is a 200, not actually checking the body or database
or validating anything.
We just had someone in the
Hey Traffic Controllers,
In order to accelerate our progress toward using and developing
traffic_ops_golang as a community, I'd like to propose that we remove
all of the dead Perl Traffic Ops API code in the repo. Many endpoints
have been rewritten in Go at this point, and by keeping the obsolete
Thanks Dan!
On Tue, Jun 19, 2018 at 3:09 PM Dan Kirkwood wrote:
> Hi all... Dave got the change done to rename our repo from
> `incubator-trafficcontrol` to `trafficcontrol`, and now the source code
> and docs on master should all reflect that.
>
> Going to
All,
The PR given below is a perl implemention for making parent.config's
go_direct directive configurable via Delivery service
https://github.com/apache/trafficcontrol/pull/2407
This PR has been hosted to discuss about various approaches to make
go_direct configurable. GoLang implementation
