ORT uses non-standard API endpoint /ort/{{host name}}/chkconfig #4437
Description
I'm submitting a ...
- improvement request (usability, performance, tech debt, etc.)
Traffic Control components affected ...
- CDN-in-a-Box (because of ORT.py)
- Traffic Ops ORT (and also the Python version used by CDN-in-a-Box)
Current behavior:
To fetch the services and their necessary states in different run-levels on cache servers, ORT calls the /ort/{{host name}}/chkconfig endpoint, which is not grounded in an API version nor documented anywhere, nor handled in Go.
Expected / new behavior:
ORT should use only real, documented, supported, versioned, API endpoints. I'm not personally very particular how that's done, though I prefer the bottom-most option (unrealistic though that may be).
• The call could be forwarded to ATSTCCFG which could be updated to support generating the output from standard API calls
• ORT itself could be changed to request the necessary information from the standard API
• The endpoint could be rewritten in Go and added to the 2.0 API.
• The ability to manage services that are not ATS could be removed from ORT entirely and left up to the orchestration or administration system in use by the organization managing the cache server, as they probably do it much better.
Minimal reproduction of the problem with instructions:
Run ORT, observe the call to an unsupported, non-standard API
Anything Else
However this is done - provided the functionality is retained - it really ought to not use the 'chkconfig' format, as all CentOS versions currently supported use SystemD instead.