DataLink availability
Closed this issue · 5 comments
Markus says it's never used and should be removed. CADC is using it probably because they have a frontend able to answer even when the service is down. Others think that when the service is down he will probably not answer to an availability request. I didn't create a pull request for that because it's undecidable at this stage for me
The capability for a service to answer it is not working supposes to operate a specific architecture such a a front-end knowing what it is working or not in the back-end.
For a client point of view having to deal with a 404, 50x or /availability is the same think.
Running /availability would be valuable to inform that a service is down for a long time (e.g. forever).
As there is no use case for this (as far as I know) I would agree with @msdemlei to removing it
In our implementation, the operation of the {links} endpoint depends on several pieces of back end infrastructure. The /availability resource allows callers that experience some other failure to check if the service is in a state where retry would be pointless. In the case of datalink, our /availability could report that:
- some back end database offline
- storage system offline
- A&A system offline
- service offline for {some reason}
This is the whole point of VOSI-availability - a common way to convey (some) operational issues and information to clients.
There are cases where the service will be down and the failure mode will also prevent access to the /availability (someone forgets to renew the SSL certificate for the front end web server/load balancer and various other sysadmin/config issues)... I don't think the fact that /availability doesn't always work means it is any less useful for the intended purpose.
I am inclined to agree with Markus that availability is rarely used, and with Pat that there are cases when it can be useful. In most cases (all known services apart from CADC??), even if clients bother to look at the availability resource, it doesn't convey any more information than that the service is up (if availability is responding and says availability=true) or not (availability is not responding). Given that, making availability mandatory seems like an unnecessary, though not particularly onerous, burden on implementors. If I was specifying this from scratch, I'd recommend making availability standard but optional. However, DALI says "All DAL services must implement the VOSI-availability resource and provide a description of this capability in the VOSI-capabilities document." (DALI 1.1 sec 24), so it's a bit problematic to try to change this for DataLink.