There is tools-static.wmflabs.org and since it's only serving static content, I think it would be great if it weren't affected by NFS maintenance and similar. Currently it's down and that's quite bad for any user experience when serving JS code that some of my gadgets at Commons load on demand, or in this case simply get stuck at loading them.
Description
Description
Related Objects
Related Objects
- Mentioned Here
- T111885: Initial Deployment of Kubernetes to Tool Labs
Event Timeline
Comment Actions
T111885: Initial Deployment of Kubernetes to Tool Labs will allow webservices that do not require NFS, but there will always be some sort of maintenance that might make tool labs unavailable for shorter or longer periods.
As for tools-static, *maybe* fs-cache (https://askubuntu.com/questions/4572/how-can-i-cache-nfs-shares-on-a-local-disk/4574#4574 et al) could be of use, but I feel most options will increase the amount of complexity (and thus will increase the possibility of failure on other points - e.g. the replication) rather than increasing the availability of the whole.
Comment Actions
So, in other words you say, I should add multiple mirrors to my scripts loading from my private servers as well if I wanted to provide a good UX.
Comment Actions
No, that currently everything is dependent on NFS and we don't have a non-NFS based solution for anything atm. Kubernetes is our non-NFS dependent setup and once that's in place we'll explore doing some form of NFS-free static file setup.
But I agree with @valhallasw that a generic 'never goes down for maintenance' is not something we can promise. We can try to decouple it from NFS and that's what the Kubernetes stuff is doing...
Comment Actions
If half an hour of downtime every now and then is problematic, I would indeed suggest other options. The most obvious one is hosting the javascript on the wiki itself (which also has other advantages such as re-using the same connection). Using your own 3rd party servers might violate the privacy policy.
Comment Actions
The most obvious one is hosting the javascript on the wiki itself
This might be a solution for certain kind of setup and if the license of the script is CC-By-SA 3.0 compatible. But there are even people who question that MIT's one is, not to talk about BSD or even GPL.
Comment Actions
Remember that some people want to be productive, even in their spare time. And any downtime causes frustration, loss of trust in the product that doesn't work in this moment, and support request (I wanted to use the tool but it got stuck, ...). Especially the last thing is what I want to avoid.
Imagine a person who uses an electronic calendar and wants to know where they have to go next and the service is interrupted for 30 min every now and then. I simply can't imagine that it's so hard offering a service that, at least doesn't go down for scheduled maintenance for static files. Thanks for working on Kubernetes to mitigate this kind of issue in the future.