+1 on removing the route. I would like to see our downstream
components migrate to something different than the giant monolithic
JSON configuration instead of moving to this new endpoint which is
essentially the same format minus some key information. I agree with
what Rob said; it was an incomplete prototype that has the potential
to mislead and confuse instead of help, and our components certainly
aren't moving to it.
Additionally, when developing goTM, we quickly discovered that our
idea to move away from the snapshots with this route and
monitoring.json was not realistic with Traffic Ops today. We should
re-evaluate the CRConfig when we decide to tackle the more targeted
config changes and/or the config state machine, because those changes
will involve consumers of the CRConfig in addition to the caching
tier(s).
--
Thanks,
Jeff
On Thu, Jul 6, 2017 at 12:38 PM, David Neuman <david.neuma...@gmail.com> wrote:
> 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
>> >
>> >
>>
