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 2020/10/29 17:29:23 UTC
[GitHub] [trafficcontrol] rawlinp opened a new issue #5218: Add delivery service server assignment safeties to Traffic Ops
rawlinp opened a new issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218
## I'm submitting a ...
- new feature / enhancement request
## Traffic Control components affected ...
- Traffic Ops
## Current behavior:
Currently, you can inadvertently cause a delivery service outage (for HTTP/DNS-types) by:
1. Unassigning all servers from an active delivery service (this one is probably the least accidental, but should probably still be prohibited)
2. Deleting the last server assigned to an active delivery service
3. Changing the status of the last server assigned to an active delivery service from REPORTED/ONLINE to any other status
## New behavior:
Each of the above things should be prevented via the API. In order to do those things, the delivery service must first be set to inactive, making it clear that the delivery service is deactivated. Upon getting a helpful error message, a CDN operator will then realize that more REPORTED/ONLINE servers should be assigned to affected DSes before unassigning/deleting/offlining the server at hand.
## Minimal reproduction of the problem with instructions:
See above.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] rawlinp commented on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
rawlinp commented on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725560274
🤔 currently we `ON DELETE CASCADE` that, which is what I think we want. I don't think we want to overburden the common case which would be deleting servers that are _not_ the last server assigned to active DSes.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] rob05c commented on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
rob05c commented on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725565068
Agreed, it'd be a big Ops pain to have to unassign every time.
But at the same time, accidentally assigning all but 1 server is going to kill most DSes, and likely that one server too. But it's difficult to automatically know exactly how many servers is reasonable.
I feel like the ideal here would be a warning message in TP, "This server is currently assigned to DS-X which has N servers assigned." But I'm not sure how difficult that is. It'd also be for every DS it's assigned to, which could potentially number in the thousands. Not sure how to make that UI reasonable. Maybe the 10 DSes with the lowest server count, or something?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] rawlinp closed issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
rawlinp closed issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] rawlinp commented on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
rawlinp commented on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725607760
> but maybe people shouldn't be allowed to create active Delivery Services and not allowed to set a DS active if it has no assigned servers/topology
I agree with that, but certain DS types can be active without having servers/topology assigned. Maybe we should revisit that with the "DS active states" overhaul.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] rob05c edited a comment on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
rob05c edited a comment on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725565068
Agreed, it'd be a big Ops pain to have to unassign every time.
But at the same time, accidentally unassigning all but 1 server is going to kill most DSes, and likely that one server too. But it's difficult to automatically know exactly how many servers is reasonable for any given DS.
I feel like the ideal here would be a warning message in TP, "This server is currently assigned to DS-X which has N servers assigned." But I'm not sure how difficult that is. It'd also be for every DS it's assigned to, which could potentially number in the thousands. Not sure how to make that UI reasonable. Maybe the 10 DSes with the lowest server count, or something?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] rob05c edited a comment on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
rob05c edited a comment on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725565068
Agreed, it'd be a big Ops pain to have to unassign every time.
But at the same time, accidentally unassigning all but 1 server is going to kill most DSes, and likely that one server too. But it's difficult to automatically know exactly how many servers is reasonable.
I feel like the ideal here would be a warning message in TP, "This server is currently assigned to DS-X which has N servers assigned." But I'm not sure how difficult that is. It'd also be for every DS it's assigned to, which could potentially number in the thousands. Not sure how to make that UI reasonable. Maybe the 10 DSes with the lowest server count, or something?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] ocket8888 commented on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725544447
Should you be able to delete servers assigned to active DSes at all? Maybe that should tell you to first un-link it from the DS.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] ocket8888 edited a comment on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
ocket8888 edited a comment on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725591018
I like to think of these things not in terms of API endpoints and alerts and restrictions - those are just implementation details - but in terms of the data model. "An Active Delivery Service cannot be made un-serviceable" seems reasonable, and so I agree with Rawlin. We could _also_ issue warnings for low-server-count DSes, but the point here is to restrict the supported data sets/operations to disallow more that cannot possibly work.
Also, though, I think "An active Delivery Service must be serviceable" also makes sense, which is a different issue, but maybe people shouldn't be allowed to create active Delivery Services and not allowed to set a DS active if it has no assigned servers/topology?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] ocket8888 commented on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
ocket8888 commented on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725591018
I like to think of these things not in terms of API endpoints and alerts and restrictions - those are just implementation details - but in terms of the data model. "An Active Delivery Service cannot be made un-serviceable" seems reasonable, and so I agree with Rawlin. We could _also_ issue warnings for low-server-count DSes, but the point here is to restrict the supported data sets to disallow more that cannot possibly work.
Also, though, I think "An active Delivery Service must be serviceable" also makes sense, which is a different issue, but maybe people shouldn't be allowed to create active Delivery Services and not allowed to set a DS active if it has no assigned servers/topology?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [trafficcontrol] rawlinp commented on issue #5218: Add delivery service server assignment safeties to Traffic Ops
Posted by GitBox <gi...@apache.org>.
rawlinp commented on issue #5218:
URL: https://github.com/apache/trafficcontrol/issues/5218#issuecomment-725574262
I have no faith that alerts alone (even in TP when they show up), will prevent bad things from happening. If operators are using the API, then the alerts will most likely be ignored altogether. By preventing at least the _last_ server from being unassigned from an active DS, the DS at least has a fighting chance of staying alive, but we can't really make assumptions about how many servers a DS might need. For some DSes, one might be perfectly suitable.
----------------------------------------------------------------
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:
users@infra.apache.org