The concept we're missing is that of a DS recycle bin. It's not uncommon for DS owners to request deletion and a day later come back and say oops. Likewise, if you're trying to determine if a DS is in use or not and switch it to Inactive presently, that only stops the router from answering. Any clients previously connected will continue to consume traffic normally (which we've seen happen for months). Normally Active/Inactive you'd think would mean that, but it doesn't and there's operational implications with how queue/snap work. It sounds like We're kindof replacing what inactive used to mean with this new primed state and making Inactive truly mean inactive so I'm +1.
Jonathan G On 4/29/20, 3:48 PM, "Jeremy Mitchell" <[email protected]> wrote: I've added some comments to this PR, Brennan. Nice work. I am curious if 3 states of Active (tr-routed/served from cache, not tr-routed but served from cache and neither tr-routed nor served from cache) is really something that is needed. I would be curious what others have to say about that..especially operators of Traffic Control. Jeremy On Mon, Apr 27, 2020 at 4:05 PM ocket 8888 <[email protected]> wrote: > I opened a blueprint PR last week to change how the DS "Active" flag works > - specifically from a boolean to an enumerated string constant. But I > forgot to alert the 'list. > > It's a relatively small change, but if you have any concerns, feel free to > voice them here: https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/pull/4654__;!!CQl3mcHX2A!XUygNSseazjAMydtQAe2xX_yilMLPt-MZACSMQnwNwgR-rwDmFNYqxkjM7_VQyB7EPFo$ > > It's still a draft because the changes can't be made until API v3, but > don't let that discourage you from leaving comments. >
