DataLink availability

[Bonnarel]

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

[lmichel]

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

[pdowler]

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.

[mbtaylor]

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.

[msdemlei]

On Sun, May 03, 2020 at 06:35:44AM -0700, Mark Taylor wrote:

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.

I'd suggest this isn't the place to discuss whether or not we want availability mandatory. Let's do this when we fix VOSI.

However, we know the way VOSI and DALI specify it doesn't work as soon as there's more than one "interesting" access URL in a resource record, as their availability may change independently of each other and it's unclear what the availability refers to.

So, either we want availability, and we'll have to change the way it's specified; if there's Datalink repeats the spec, this would mean we'll have to touch Datalink again at that point.

Or we don't want availability as a common thing on all our interfaces, in which case we don't need to specify it in Datalink in the first place.

In both cases: We shouldn't put it here. It buys us nothing, but it will cost us later in both cases, if only because we'll have to edit Datalink again. If there's a strong feeling we need to say more about all this, I think the best we can reasonably do is "DALI 1.x requirements apply" or so.

[pdowler]

Since the mention of VOSI resources was removed in #37 I am closing this.