Consider use of JupyterHub's announcement template variable influencing default templates

[consideRatio]

Background

This is a "JupyterHub Announcement".

It has also been considered in 2i2c-org/team-compass#423 for scheduling downtime.

Idea

It could make sense to explore if/how the not well documented announcement feature of jupyterhub's html templates could be used to help hub champions communicate smaller messages, for example via the JupyterHub Configurator where they can configure some things for themselves, or maybe via a default-home-page provided jupyterhub_config.py which is a system etc I don't understand how it works but seem to include similar configuration.

These announcement snippets can be configured via c.JupyterHub.template_vars in the announcement or announcement_<specific page> key.

page.html template

{% block announcement %}
{% if announcement %}
<div class="container text-center announcement alert alert-warning">
  {{ announcement | safe }}
</div>
{% endif %}
{% endblock %}

login.html template

{% extends "page.html" %}
{% if announcement_login %}
  {% set announcement = announcement_login %}
{% endif %}

Important considerations

• Does a change of c.JupyterHub.template_vars post-startup of the hub change how templates are rendered?
  • If not, can jupyterhub's state be affected post-start in another way?
  • If not, can jupyterhub be adjusted to account for changes over time, reloading some config dynamically or given some trigger etc?
• Are announcement only shown to non-signed in users? No to all if announcement is set.
  • Can something be done? Yes, but see announcement_login etc can't be set falsy to override announcement jupyterhub/jupyterhub#3965
  • 2i2c already adjust things, so this can be in conflict with that. For example, I note that https://github.com/2i2c-org/default-hub-homepage/blob/master/jupyterhub_config.py assigns to c.JupyterHub.template_vars without considering its previous value, therefore possibly ignoring anything done to template_vars elsewhere.

---

Note that I'm not looking to work on this myself, just wanted to follow up this idea I got properly after reading and thinking about #1300 (comment).

[rcthomas]

Hi! I came across this while looking at the Hub issue tracker for a different reason. But reading your considerations and some of the other issues I wondered if you'd seen/considered this Hub service I made a few years ago, and have been using in my deployment for alerting users to issues, maintenances, etc: https://github.com/rcthomas/jupyterhub-announcement

To my surprise people besides myself have actually been using it. It's not overly sophisticated, the point is for it to be a very simple service, but I like that I and other admins can update the messages without having to reload hub config, etc.

I've been spending some time of late as my schedule allows, trying to shape it up and properly release it. If folks took a look at it and said "not for us" then that's OK, but I'd be grateful for any feedback about what's not right about it or what might need to change with it. In any case I just thought I'd mention it.

[choldgraf]

that is super cool @rcthomas ! One thought: you should post a screenshot of what the announcement looks like! I see screenshots of what the admin-facing UI looks like (which is nice!) but no idea of what the end result looks like!

[rcthomas]

D'oh that would make sense wouldn't it @choldgraf? I've put that on the README fix-up list and I'll add that.

But the spoiler is that if you follow the example in the README and just extend the default JupyterHub templates it'll end up looking like the banner @consideRatio showed at the top of the issue here.

I think the appearance is OK but it seems at odds with the default JupyterHub style. I'm not sure it should be "JupyterHub orange" but I think it's just using a preset class from bootstrap.

[rcthomas]

@choldgraf Finally addressed your suggestion, also released to PyPI

[choldgraf]

Signal boost: this would be useful for the holiday period

We discussed in our team strategy meeting that we need a way to project information to users and decision makers when there is expected upcoming downtime. In that meeting we noted that the ability to quickly send a banner message to all of our hubs (or to a subset of hubs) would be very useful.

Just adding this point here to signal boost this idea's value.

[damianavila]

@sgibson91, could it be the case that in the recent conversation about this one you were talking about the implementation proposed by @consideRatio at the top whereas I was thinking into (and talking about) the @rcthomas implementation?
That might explain some of the confusion in the specifics of the brief discussion (or maybe it was me and I just failed to correctly understand you).

[sgibson91]

Yeah, probably, didn't know there was different implementations. Tbf, allowing admins to add announcements to their own hubs through a page doesn't seem like the worst idea, especially for education hubs?

[damianavila]

Tbf, allowing admins to add announcements to their own hubs through a page doesn't seem like the worst idea, especially for education hubs?

Yep, I see value in that idea.

[rcthomas]

Sorry I missed the conversation, because after using this feature in the templates with the announcement service for some time I have some thoughts and observations. I'll leave them here. We're not an education hub per se, though our hub is used by educators and their students.

• Users definitely appreciate advance notice of anything disruptive
• If there are ongoing issues, users like knowing the humans behind the wall are aware there are issues
• The announcement service model allows an update of the announcement without a redeploy, I've found that convenient

Things that aren't perfect about it (and the announcement feature generally):

• You do have to modify the page template to talk to the service but that's only a one time operation
• The default styling of the message is kind of not in alignment with the rest of the hub, that could be better
• Persistent issues tend to fade into the cognitive background for users, so it's better to use sparingly
• ... but at the same time, again, users want your acknowledgment of ongoing issues (it's a catch-22)
• Users may go a long time without even seeing the hub, so you may want something in the notebook server to poll the service periodically and somehow, yet non-disruptively, let users know there is a message they may want to check (this is a plus in favor of a service-oriented approach to messaging)

I originally put the service together as a kind of learning exercise for myself but also because the nature of my environment is that there's a lot of evolution going on, and the hub depends on several subsystems that can be having issues, and I found users just didn't avail themselves of information we provided through other channels. We've moved in the direction of making general subsystems status available via API for automated workflows, and I've added an extension to the announcement service that lets the service read that API and funnel the information into the same message stream.

That is to say that our message sources include the page but also other services, and some of the messages posted come without any hub admin action at all, so while the page is indeed not the worst idea, the best idea may be a service-oriented approach (whether it includes a page interface or not) over something more static.

[damianavila]

This is great feedback @rcthomas, thanks for sharing it with us!!

[consideRatio]

Pingback from Emilio at oceanhackweek in this freshdesk ticket that jupyterhub-announcement!