rawlinp opened a new issue #3542: Deprecate STEERING in favor of CLIENT_STEERING
URL: https://github.com/apache/trafficcontrol/issues/3542
 
 
   We should deprecate STEERING delivery services in favor of a singular 
CLIENT_STEERING delivery service type. For the most part, a CLIENT_STEERING 
delivery service can provide the same set of functionality as a STEERING 
delivery service. There are only a few things that apply to STEERING and not 
CLIENT_STEERING:
   1. The "x-tc-steering-option" header can be used by a client to request a 
specific steering target in a STEERING delivery service.
   2. Delivery service STEERING_REGEXPs (a.k.a. "steering filters") only apply 
to STEERING.
   3. The JSON response format when using the query string `?format=json` 
varies slightly between STEERING and CLIENT_STEERING:
   
   STEERING:
   ```
   {"location": "http://myedge.myds.mycdn.example.net/foo?format=json"}
   ```
   CLIENT_STEERING:
   ```
   {"locations":["http://myedge.myds.mycdn.example.net/foo?format=json"]}
   ```
   
   That said, if no clients of a STEERING delivery service use the above 3 
features, they should be able to smoothly transition to an equivalent 
CLIENT_STEERING delivery service instead. They will still get 302'd by default, 
but with CLIENT_STEERING they will also receive the full result list of all 
targets (which they could choose to ignore). If the STEERING clients only care 
about the 302, ignore the response body, and don't use `?format=json`, then 
their experience shouldn't change between a STEERING delivery service and an 
equivalent CLIENT_STEERING delivery service.
   
   However, if the STEERING client depends on the specific JSON format provided 
via `?format=json`, then they will need to be fixed to work with the 
CLIENT_STEERING JSON format. Other than that, we could add functionality to 
CLIENT_STEERING to satisfy points 1 and 2 for STEERING clients that use those 
features still.
   
   I think a tentative plan would look like this:
   - add functionality for points 1 and 2 to CLIENT_STEERING (possibly, if the 
community still relies on that obscure functionality)
   - deprecate STEERING in major release N -- no new delivery services of type 
STEERING can be created, but existing STEERING delivery services will continue 
to be supported. Delivery services of type CLIENT_STEERING can be created, and 
existing STEERING delivery services should be updated to use CLIENT_STEERING 
instead.
   - in major release N+1, remove support for STEERING-type delivery services. 
This would include removing the STEERING type from Traffic Ops, removing 
non-CLIENT_STEERING support in the CRConfig, and removing non-CLIENT_STEERING 
support in Traffic Router. By this point, release N+1 could probably include a 
DB migration that automatically sets any remaining STEERING delivery services 
to CLIENT_STEERING, because everyone should have manually transitioned to 
CLIENT_STEERING before release N+1 anyways.
   
   Relevant mailing list thread: 
https://lists.apache.org/thread.html/0dbb85f752267f3730e9801c3ff6e01a6e5e1676a7145f972fe74e51@%3Cdev.trafficcontrol.apache.org%3E

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to