How to deactivate the event log?

Is there an easy way to deactivate the event log? It’s nice to see for administrators what is going on, but I think that in most cases it is confusing for regular users. For example, there should be no need for users to see that a node didn’t match a Pod’s node affinity/selector before a scaleup is triggered correctly. Information about the maximum number of nodes, image names and where they are stored also seem to be unnecessary for regular users. The progress bar should be sufficient :slight_smile:

Try setting = False:

1 Like

This works, but unfortunately it also kills the progress bar progression, which is just left as an empty box. Is there a way to maintain the progress bar progression, while leaving out the written event log details? This would be an elegant solution :slight_smile:

Your suggestion is almost there, but without the progression it’s very easy to be in doubt if anything is happening at all. It seems to take an incredibly long time if a new node needs to be started without the progress bar progression.

This is the code controlling the progress display: kubespawner/ at b9fc97099ce9bf25376f68090f4fd9499b97f812 · jupyterhub/kubespawner · GitHub
You could subclass KubeSpawner and override progress() to change the returned progress information:
kubespawner/ at b9fc97099ce9bf25376f68090f4fd9499b97f812 · jupyterhub/kubespawner · GitHub

1 Like

Just to make sure that I fully understand your suggestion, I am thinking about overwriting the code you marked in async def progress(self) with:

                    yield {
                        'progress': int(progress)

Is there a best practice for how to subclass KubeSpawner for z2jh? I am unfortunately unable to find a guide.

The above could also be the suggested behavior for = False. I think that the current implementation with an empty progress bar is unfortunately making people uneasy (that’s my experience at least).

You can make small changes inline in the Z2JH config

Something like this should work (might not be quite right as I’m writing this from memory):

    00-custom-spawner: |
      from kubespawner import KubeSpawner
      class MyCustomSpawner(KubeSpawner):
        def parent_function_to_be_overridden(self, ...):
      c.JupyterHub.spawner_class = MyCustomSpawner

I haven’t thought about this, but if you can come up with a full proposal please open an issue on GitHub - jupyterhub/kubespawner: Kubernetes spawner for JupyterHub

This works as a quick fix. Basically changing:

                    yield {
                        'progress': int(progress),
                        'raw_event': event,
                        'message': "%s [%s] %s"
                        % (
                            event["lastTimestamp"] or event["eventTime"],


                    yield {
                        'progress': int(progress),

in progress().

The event log looks a bit funny if you click on it:

But it’s still better than an empty progress bar :slight_smile:

Is it possible to disable the event log in an easy way? For example singleuser.event_log = False:? If that’s possible, it will be straightforward to achieve the desired result immediately.

Not the most elegant solution, but if your main goal is hiding the text, you could add CSS to the spawn_pending.html template to hide div#progress-details:

{% extends "templates/spawn_pending.html" %}
{% block script %}
{{ super() }}
<style type="text/css">
div#progress-details {
  display: none;
{% endblock %}
1 Like

Thank you for your input. I will consider this option. I’ve also opened an issue in the kubespawner repo: Enable progress bar progression for = False: · Issue #701 · jupyterhub/kubespawner · GitHub

With the hope that a more permanent solution can be found with = False. I believe the current configuration leaves people uneasy, so it’s unlikely to be used. The empty progress bar leaves the impression that nothing is happening, and the spawn time feels incredibly long as a consequence.

I’ve also come to think that the messages are mainly useful for cluster admins, while users should perhaps by default not see all these details. Some of the messages give warnings that users are likely to confuse for something being wrong, while the reality is that the cluster is simply scaling up as it should.