Fix DS "ACTIVE" flag to work as expected

[rgresino]

It appears that this is not what this does. This does not remove traffic from a DS or inactivate it. It removes the DS from the Traffic Router so it is not routed to. Any established connections like linear streams will continue to use this delivery service since they rarely, if ever, go back to the traffic router.We need something that sets a flag so that the DS is held in TODB, but is not copied into records.config on the caches, so that the DS is removed from the caches, but could be re-enabled quickly, but not deleted from TODB (and the associated Keys and Certs deleted from Traffic Vault.)

[rob05c]

Big +1. This is a terrible foot-gun. It's incredibly unintuitive, and further, if the wrong DS were left inadvertently serving at the edge, it could easily be a security issue.

I suggest we add an additional DS flag, "active-caches," and rename this in the UI to reflect that it is "active-routed." Of course, with documentation and UI tooltips indicating exactly what each does.

The "active-caches" flag to remove a DS from cache configs should be a tiny amount of work, it's basically a single if-statement in remap.config generation, unless I'm mistaken.

I'm also +1 on labelling this 'bug' and 'major'. It may have been by-design, but it's a dangerous and deceptive design, and effectively a user interface bug.

[mitchell852]

@rob05c - active-routed AND active-caches? would you ever want active-routed=false, active-caches=true or vice versa? I thought the fix here was simply if DS.active=false exclude from crconfig (snapshot) and any/all applicable cache config files (maybe an oversimplification).

[rgresino]

Have to snap before you can remove from ATS. So it is a two step process.

[rob05c]

would you ever want active-routed=false, active-caches=true or vice versa?

Yes. You might want to stage the removal, to remove a DS from routing, and then make sure the Origin own was right and there actually aren't clients still going to caches, and then remove from the cache maybe a week later.

Likewise, you may want to stage a new deployment to caches, and test that your requests to the cache work as expected, before deploying globally to the Router.

Being able to "stage" the router-cache deployment changes is a big safety win for operations.

[ocket8888]

As of today, inactive DSes are already omitted from remap.config generation, I think parent.config is the only place they will have data inserted. I think.

[mitchell852]

removed bug label and applied tech debt label as this is more a product of bad design imo. don't worry, it's being addressed regardless by @ocket8888