Hi there, The question of how to get an announcement to users running in JupyterLab has been asked before, and I think what Jason suggests is the answer. The jupyterhub-announcement service has an API endpoint `/latest` that returns the latest message, when and who posted it. JupyterLab could just call that periodically. If the "hey log off" message is something you want sent immediately the more fancy websocket option would be the way to go though we'd have to add that to the service. There's an issue open on jupyterhub-announcement right now about it but it's a bit stale, maybe we can revive the conversation. I do think at this point it's more of a JupyterLab implementation/extension question (except for the push part).
What we do for nologin-like stuff at our Center is a bit rough, but it mostly works. We update the hub configuration to allow only admin logins (via the allow-only list) and then use an admin-managed script or the admin interface to shut down all the servers. Users don't get any warning about it of course and with a large number of users on it can take a while; our script version is parallelized. I think it's not perfect but it's good enough for when we really need the notebooks to stop for some reason. If there's a scheduled maintenance I start shutting down idle servers a little bit ahead of time to keep any maintenance window short. On Wednesday, September 2, 2020 at 3:46:30 AM UTC-7 Jason Grout wrote: > If you wanted to implement a front-end extension for, say, JupyterLab, you > could do this. Basically, the extension would have two parts: a server part > that creates an api endpoint (i.e., a url that can be polled, like `/motd`) > and a frontend part that polls the url asking for a message and displays a > message if there is one. Or slightly fancier would be an api endpoint that > uses some sort of push method (websocket, or even long polling, or > something) - that way a message could be pushed to the server without > having to wait for a polling interval. > > Jason > > > On Wed, Sep 2, 2020 at 2:26 AM Norman Gray <norman...@gmail.com> wrote: > >> >> Michael, hello. >> >> On 1 Sep 2020, at 18:20, 'Michael Milligan' via Project Jupyter wrote: >> >> > I'm not aware of a "nologin" type solution, but it sounds simple >> > enough >> > that someone has probably implemented one. >> >> It does sound quite simple. Having created a mildly customised spawner >> before, I imagine I could hack up something like this myself, but... >> must resist... must resist... >> >> > Unfortunately the weak link here is communicating with users who are >> > already in running sessions. Jupyterhub can't easily help there, as by >> > that >> > time the user experience is under the control of the notebook server, >> > jupyterlab, or whatever frontend they happen to be using. So your >> > solution >> > will depend on what your users are actually doing. I'd also be curious >> > to >> > know if others in this forum have solutions for that. >> >> Right, I see. I could imagine there being some sort of hook in there >> which we could use, but if control is handed over to the notebook >> server, I can appreciate that would be hard. >> >> So maybe this is more of a jupyterlab question, than a jupyterhub one. >> >> Best wishes, >> >> Norman >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Project Jupyter" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jupyter+u...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/jupyter/AB5AF6AB-7205-42FF-A8ED-54CFF747C8F0%40gmail.com >> . >> > -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/7f98f46b-2bb4-4443-8440-5f53b57da3ddn%40googlegroups.com.
