Hey Rawlin,
I took a look through our splunk logs and it looks like we don't have
anything at Comcast that has hit that endpoint in the last 90 days.
For this reason, I am +1 on removing.
Thanks,
Dave
On Thu, Jul 6, 2017 at 11:27 AM, Robert Butts <robert.o.bu...@gmail.com>
wrote:
> This isn't obsolete, so much as a prototype. It was intended to be "better"
> than the CRConfig and replace it for TR. Much the same way
> `configs/monitoring.json` is the "next generation" endpoint for Traffic
> Monitor (and which is now used in the Golang TM).
>
> That said, as you say, it's incomplete and not currently in use by Traffic
> Control, and probably not useful. I don't have a strong opinion, if you
> want to push for deprecating and removing it. I do have a strong opinion,
> that it should be marked "deprecated" in the next release, and removed in
> the release after, not immediately removed. That should be the normal
> procedure, we should give anyone using Traffic Control a chance to migrate
> before removing things.
>
>
> On Thu, Jul 6, 2017 at 11:14 AM, Peters, Rawlin <rawlin_pet...@comcast.com
> >
> wrote:
>
> > Hey all,
> >
> > I believe I’ve found an obsolete/broken API endpoint [1] that might be a
> > good candidate for removal. Here is an example request:
> >
> > GET /api/1.2/cdns/mycdn/configs/routing
> >
> > This will return a json object that looks like the following:
> >
> > {
> > “response”: {
> > “trafficServers”: […],
> > “stats”: {…},
> > “cacheGroups”: […],
> > “config”: {…},
> > “trafficMonitors”: […],
> > “trafficRouters”: […]
> > }
> > }
> >
> > As you might notice, this looks very similar to CRConfig.json except that
> > most of the keys are named differently (e.g. “trafficRouters” vs.
> > “contentRouters”). There is a lot of overlapping information between this
> > and CRConfig which makes me believe that perhaps this API was a precursor
> > to CRConfig that is now obsolete. Further evidence that it’s out-of-date
> > includes (among other things) missing “httpsPort” fields in the objects
> and
> > empty “deliveryServices” arrays for every “trafficServer” object (the
> > arrays shouldn’t be empty if there are delivery services assigned). Also,
> > it seems to be targeted for Traffic Router usage, but Traffic Routers
> > currently pull their CRConfig from Traffic Monitors.
> >
> > The following API endpoints [2][3] seem to provide more up-to-date
> > information via CRConfig and should already replace the outdated endpoint
> > above:
> >
> > GET /api/1.2/cdns/mycdn/snapshot
> > GET /genfiles/view/bycdnname/mycdn/CRConfig.json
> >
> > I propose that we remove this API endpoint [1] unless someone can verify
> > that it’s still in use somewhere (with a good reason to not use a
> CRConfig
> > endpoint instead). I will wait a few days for responses before starting
> on
> > a Pull Request to remove it.
> >
> > Thanks,
> > Rawlin Peters
> >
> > [1] https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L469
> > [2] https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L439
> > [3] https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L331
> >
> >
>
