I'm definitely +1 on this. Good idea!
> On May 2, 2019, at 9:32 AM, Jeremy Mitchell <mitchell...@gmail.com> wrote:
>
> 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 <neu...@apache.org> 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 <rawlin.pet...@gmail.com>
>> 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
>>>
>>
