Good suggestion, Rawlin. +1 I'm always in favor of any sort of simplification and this sounds like a good one. As always, I'd suggest creating an issue ( https://github.com/apache/trafficcontrol/issues) and put your explanation in there and we can mark it as "tech debt" and hopefully we can find the time to get it done.
On Wed, May 1, 2019 at 6:41 PM Dave Neuman <[email protected]> wrote: > +1. I don’t think we actually use (old) steering anywhere in production. > Steering does support the regex feature (use a regex to “pin” to a DS) and > I don’t think the client_steering does, so we might want to consider moving > that feature into client_steering. Steering also supports an overwrite > header that may or may not be in client steering. > > On Wed, May 1, 2019 at 13:14 Rawlin Peters <[email protected]> > wrote: > > > Hey all, > > > > I think we should consider deprecating the STEERING delivery service > > type in favor of CLIENT_STEERING. > > > > tl;dr: > > Everything that a STEERING delivery service provides can be provided > > by a CLIENT_STEERING delivery service instead, and CLIENT_STEERING > > provides more advanced features like Geolocation-based steering that > > are not available to the plain STEERING type. There are some small > > differences in request payloads when passing the `?format=json` query > > parameter, but other than that the client-facing interface is the same > > between CLIENT_STEERING and STEERING. > > > > What do you think of this proposal? Can you think of a good reason why > > we should keep STEERING in addition to CLIENT_STEERING? If you're > > skeptical or unsure, feel free to read the longer explanation below. > > > > > > Longer explanation: > > The main difference in the results returned by STEERING vs > > CLIENT_STEERING is that the STEERING result only contains the "top" > > target. This "top" target can still be returned as a json payload, as > > a 200 or a 302, depending on query parameters passed in the request, > > which is the same behavior as CLIENT_STEERING. However, > > CLIENT_STEERING will include *all* of the possible targets not just > > the "top" target. > > > > For clients that just consume and follow the 302, changing the > > delivery service from STEERING to CLIENT_STEERING won't really affect > > the clients -- that behavior would stay the same. However, if clients > > of the STEERING-type are passing `?format=json` in the request, that > > JSON payload differs slightly from STEERING to CLIENT_STEERING. > > > > For STEERING, the payload looks like this: > > {"location": "http://myedge.myds.mycdn.example.net/foo?format=json"} > > For CLIENT_STEERING, it uses an array like this: > > {"locations":["http://myedge.myds.mycdn.example.net/foo?format=json"]} > > > > For either STEERING or CLIENT_STEERING, if the client passes > > `?trred=false` to get a 200 response instead of a 302, the payload > > formats are the same. > > > > So, we couldn't really automatically convert all STEERING DSes to > > CLIENT_STEERING through a DB migration because of those small > > differences in the `?format=json` payloads between the two, but we > > could at least prevent the creation of new STEERING-type DSes during > > the deprecation period and encourage existing STEERING-type DSes to be > > converted to CLIENT_STEERING. Then after a major release or two we can > > draw a line in the sand and automatically convert STEERING types to > > CLIENT_STEERING, and/or make it a requirement that all STEERING-types > > must be converted to CLIENT_STEERING before a certain major release. > > > > Eliminating the STEERING type would allow us to simplify Traffic > > Router a little bit and make it less confusing for users by not having > > two different STEERING types to choose from. Going forward a lot of > > new features are only being added to the CLIENT_STEERING type because > > they don't really apply to STEERING, so the feature disparity between > > the two is only going to grow. > > > > - Rawlin > > >
