Page MenuHomePhabricator

Static content should be always up, or there should be a place where I can put static content and that place should be always up.
Closed, DeclinedPublic


There is 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.

Event Timeline

Rillke raised the priority of this task from to Low.
Rillke updated the task description. (Show Details)
Rillke added a project: Toolforge.
Rillke added a subscriber: Rillke.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
valhallasw claimed this task.
valhallasw added a subscriber: valhallasw.

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 ( 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.

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.

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...

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.

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.

If half an hour of downtime every now and then is problematic

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.