You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2021/08/12 20:54:50 UTC

[GitHub] [trafficcontrol] rob05c commented on pull request #6095: Layered Profile Blueprint

rob05c commented on pull request #6095:
URL: https://github.com/apache/trafficcontrol/pull/6095#issuecomment-897960910


   > One other thing I just thought of: how is backwards compatibility handled for objects with layered Profiles? If I have a server with:
   
   I put a lot of thought into this in my initial proposal. I came up with some options, but they're _really_ hacky. 
   
   Honestly, I think the best solution is probably to return a 4xx code from /servers and /deliveryservices if a user has assigned more than 1 Profile. And to warn users when they do, that this will break old clients. Which is _mostly_ ok in practice, it _mostly_ means people just have to upgrade all ATC components and clients before they start using Layered Profiles.
   
   I don't suggest that lightly. IMO breaking backward compatibility is one of the worst things we can do, in terms of usability, maintaining users, I could go on. But I honestly think the alternative is probably worse here.
   
   See https://cwiki.apache.org/confluence/display/TC/Layered+Profiles for some of my compatibility ideas.
   
   > I assume it'd never choose a middle Profile and would always choose consistently, but should we use the "bottom" Profile 
   
   We can't return any single real profile. If someone assigned multiple Profiles, those Parameters, in that exact order, are necessary. Anything that looks at a single profile for params will be broken. If you look at that wiki link, most of my ideas are around creating a "fake" profile. But IDs and names make that hard, and you still can't edit it, so POST/PUT still return error codes. Unless you did even more hacks.


-- 
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.

To unsubscribe, e-mail: issues-unsubscribe@trafficcontrol.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org