3:25 a.m.
[ I will send a follow up email for "computed resource state" ]
We've discussed a bit about availability vs uptime.
First question: Do we need to distinguish ? Is it important for someone
who wants to know if his website is accessible to really separate the 2
concepts. (Details vs simplicity)
Isn't uptime a function of availability over time?
And even this is not always correct if you take a machine that has been powered up and is
up for 4 weeks, then its uptime is 4 weeks. If someone in the middle of the 4 weeks pulls
the power cord on the network switch, then it may not be available (for business) for a
while, but it is still up.
But if we take this edge case away (because when connectivity is up again, we can find out
with the uptime(1) command that it indeed was up all the time). The two match nicely.
Second question: If we separate the 2, how do we do distinguish ? A
suggestion:
* HTTP Code 2xx and 3xx -> URL is up and available
+1
* HTTP Code 4xx -> The server may reject the request (it may not
like
bots, user entered a wrong url (should be checked upfront), or resource
has been deleted)... Server is up, availability is unknown
* HTTP Code 5xx -> URL is up but not available
* Timeout -> URL is down and not available
Couldn't resolve host 'www.fffffffffefwefdwdf.com' -> Domain name is
deleted: URL is down and not available
Here we might need to even have special handling if this happens when the url is first
entered,
and ask the user in case of error if this entered url was "wrong" on purpose
(Test-Driven-Ops)
or not.
4xx is likely the most debatable, it's a client issue and likely needs
either code fix or user intervention... (And we can't unfortunately
expect servers to fully respect the codes)
Usually for a client user that wants to shop at acme.com, it does not matter if the server
returns a 500 or a
404 - Shop not found.
In a more general case one can argue that it is the business of a feed to determine the
values for availability.