Support Queuing Updates by Server Type

[dsouza93]

I'm submitting a ...

• new feature / enhancement request

Traffic Control components affected ...

• Documentation
• Traffic Ops
• Traffic Ops ORT
• Traffic Portal

Current behavior:

There has been the need to queue only the edge caches or only the mid caches. Currently, this has to either be done by writing a script to hit the API, or hacky ways like admin_downing mid caches in each cache group to queue updates on edges.

Expected / new behavior:

I'd like the ability to only queue updates on a specific tier. To expand on this it might be nice to be able to queue based on a profile regex as well.

Minimal reproduction of the problem with instructions:

N/A

Anything else:

[mitchell852]

currently you can queue updates on servers at 3 levels:

1. all servers in a cdn
2. all servers in a cache group
3. an individual server

I know that #3 will also queue updates on any "child" servers of that server automatically. I'm not sure if #2 does the same thing. I.e. if you queue updates on a cache group's servers, does it also queue updates on any servers in child cache group(s). I'd need to look into that.

my point being, when you say "queue updates by server type", you really only want updates queued for servers of that type and NOT "children" servers as it does now, correct? Example, if you want to queue updates on all MID servers, you only want those MID servers queued, right? nothing else....

[mitchell852]

Maybe we need to consider a new endpoint like:

POST (or PUT) /api/queue_updates with a bunch of supported query params such as:

/api/queue_updates?cdn=
/api/queue_updates?cacheGroup=
/api/queue_updates?server=(hostname? id? both?)
/api/queue_updates?type=
/api/queue_updates?profile=
/api/queue_updates?topology=
/api/queue_updates?deliveryService=(xmlId? id? both?)
/api/queue_updates?physLocation=
/api/queue_updates?serverCapability=
/api/queue_updates?status=

that would give the user lots of options on how they wan to queue updates :)

[srijeet0406]

@mitchell852 I can take this one.

[srijeet0406]

Talked to @mitchell852 about this, and for this issue, I'll be adding queueing updates by Type and profile only. We can keep adding to that endpoint later as we'd like.

[dsouza93]

Queueing updates by type and profile only seems acceptable and more user friendly! Sounds good to me.

[rawlinp]

Rather than adding a new endpoint, would it make sense to just add type and profile query parameters to the existing /cdns/{id}/queue_update endpoint? I think most of the time you're queuing within a single CDN, so it might make sense to keep it CDN-specific, but within that CDN you can narrow down by server type and profile.

I would prefer us to move away from having to do targeted queues in the first place -- in general if you queue updates on a server that doesn't actually have updates, it should be a no-op. The problem is that it adds load on Traffic Ops to serve requests from t3c when they're not actually needed. However, we are trying to get to a point where Traffic Ops can easily handle the load from thousands of t3c instances at a time, so eventually we should be able to just queue entire CDNs at a time and have the change fully propagated in a few minutes rather than an hour.

[mitchell852]

Rather than adding a new endpoint, would it make sense to just add type and profile query parameters to the existing /cdns/{id}/queue_update endpoint? I think most of the time you're queuing within a single CDN, so it might make sense to keep it CDN-specific, but within that CDN you can narrow down by server type and profile.

this makes sense to me. i think most (all?) of the time, you are concerned with a specific cdn anyhow.