Skip to main content
The desktop app updates itself. In a cluster, Lumovi is upgraded like anything else Helm installed: you upgrade its chart. The chart is released with Lumovi itself, so the chart’s version is the app’s.

​
Upgrade

1

See what's new

Each version’s changes are in the changelog and on GitHub releases.
2

Upgrade the chart

Without --version, Helm installs the latest. The image’s tag follows the chart unless you set image.tag.
3

Check it started

The first line of the log names the version that’s running.

​
What people see

Sessions live in Lumovi’s memory, so a new pod signs everyone out. Open pages reconnect to the new pod by themselves, and show the sign-in page. With single sign-on, signing in again is a click; with tokens, people paste one again. Behind an authenticating proxy, Lumovi keeps no sessions of its own, so nobody notices more than a reconnect. The same goes for any change that replaces the pod: changing a setting, or the views everyone sees.
For the same reason the chart runs one replica. More than one would need sticky sessions, and each replica would still keep its own sessions.

​
When the client secret changes

A change to a Secret’s contents doesn’t replace the pod. Lumovi reads the single sign-on client’s secret from an environment variable, when the pod starts, so it keeps the old one until it restarts. That’s the case when you change auth.oidc.clientSecret and upgrade (the chart changes its Secret, not the pod), and when you change the Secret that auth.oidc.existingSecret names. Restart Lumovi so it reads the new secret:
Like any restart, this signs everyone out.

​
Roll back

Helm keeps the previous revision, so going back is one command:
helm history lumovi --namespace lumovi lists the revisions, and helm rollback lumovi <revision> --namespace lumovi goes back to a particular one.

Changelog

What changed in each version.

Helm values

Every setting the chart has.