diff --git a/slides/k8s/helm.md b/slides/k8s/helm.md
index 5c895daa..253a23b6 100644
--- a/slides/k8s/helm.md
+++ b/slides/k8s/helm.md
@@ -22,9 +22,9 @@
 
 - `helm` is a CLI tool
 
-- `tiller` is its companion server-side component
+- It is used to find, install, upgrade *charts*
 
-- A "chart" is an archive containing templatized YAML bundles
+- A chart is an archive containing templatized YAML bundles
 
 - Charts are versioned
 
@@ -32,6 +32,90 @@
 
 ---
 
+## Differences between charts and packages
+
+- A package (deb, rpm...) contains binaries, libraries, etc.
+
+- A chart contains YAML manifests
+
+  (the binaries, libraries, etc. are in the images referenced by the chart)
+
+- On most distributions, a package can only be installed once
+
+  (installing another version replaces the installed one)
+
+- A chart can be installed multiple times
+
+- Each installation is called a *release*
+
+- This allows to install e.g. 10 instances of MongoDB
+
+  (with potentially different versions and configurations)
+
+---
+
+class: extra-details
+
+## Wait a minute ...
+
+*But, on my Debian system, I have Python 2 **and** Python 3.
+<br/>
+Also, I have multiple versions of the Postgres database engine!*
+
+Yes!
+
+But they have different package names:
+
+- `python2.7`, `python3.8`
+
+- `postgresql-10`, `postgresql-11`
+
+Good to know: the Postgres package in Debian includes
+provisions to deploy multiple Postgres servers on the
+same system, but it's an exception (and it's a lot of
+work done by the package maintainer, not by the `dpkg`
+or `apt` tools).
+
+---
+
+## Helm 2 vs Helm 3
+
+- Helm 3 was released [November 13, 2019](https://helm.sh/blog/helm-3-released/)
+
+- Charts remain compatible between Helm 2 and Helm 3
+
+- The CLI is very similar (with minor changes to some commands)
+
+- The main difference is that Helm 2 uses `tiller`, a server-side component
+
+- Helm 3 doesn't use `tiller` at all, making it simpler (yay!)
+
+---
+
+class: extra-details
+
+## With or without `tiller`
+
+- With Helm 3:
+
+  - the `helm` CLI communicates directly with the Kubernetes API
+
+  - it creates resources (deployments, services...) with our credentials
+
+- With Helm 2:
+
+  - the `helm` CLI communicates with `tiller`, telling `tiller` what to do
+
+  - `tiller` then communicates with the Kubernetes API, using its own credentials
+
+- This indirect model caused significant permissions headaches
+
+  (`tiller` required very broad permissions to function)
+
+- `tiller` was removed in Helm 3 to simplify the security aspects
+
+---
+
 ## Installing Helm
 
 - If the `helm` CLI is not installed in your environment, install it
@@ -45,14 +129,21 @@
 
 - If it's not installed, run the following command:
   ```bash
-  curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash
+  curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get-helm-3 \
+  | bash
   ```
 
 ]
 
+(To install Helm 2, replace `get-helm-3` with `get`.)
+
 ---
 
-## Installing Tiller
+class: extra-details
+
+## Only if using Helm 2 ...
+
+- We need to install Tiller and give it some permissions
 
 - Tiller is composed of a *service* and a *deployment* in the `kube-system` namespace
 
@@ -67,8 +158,6 @@
 
 ]
 
-If Tiller was already installed, don't worry: this won't break it.
-
 At the end of the install process, you will see:
 
 ```
@@ -77,9 +166,11 @@ Happy Helming!
 
 ---
 
-## Fix account permissions
+class: extra-details
 
-- Helm permission model requires us to tweak permissions
+## Only if using Helm 2 ...
+
+- Tiller needs permissions to create Kubernetes resources
 
 - In a more realistic deployment, you might create per-user or per-team
   service accounts, roles, and role bindings
@@ -92,6 +183,7 @@ Happy Helming!
       --clusterrole=cluster-admin --serviceaccount=kube-system:default
   ```
 
+
 ]
 
 (Defining the exact roles and permissions on your cluster requires
@@ -100,79 +192,228 @@ fine for personal and development clusters.)
 
 ---
 
-## View available charts
+## Charts and repositories
 
-- A public repo is pre-configured when installing Helm
+- A *repository* (or repo in short) is a collection of charts
 
-- We can view available charts with `helm search` (and an optional keyword)
+- It's just a bunch of files
+
+  (they can be hosted by a static HTTP server, or on a local directory)
+
+- We can add "repos" to Helm, giving them a nickname
+
+- The nickname is used when referring to charts on that repo
+
+  (for instance, if we try to install `hello/world`, that
+  means the chart `world` on the repo `hello`; and that repo
+  `hello` might be something like https://blahblah.hello.io/charts/)
+
+---
+
+## Managing repositories
+
+- Let's check what repositories we have, and add the `stable` repo
+
+  (the `stable` repo contains a set of official-ish charts)
 
 .exercise[
 
-- View all available charts:
+- List our repos:
   ```bash
-  helm search
+  helm repo list
   ```
 
-- View charts related to `prometheus`:
+- Add the `stable` repo:
   ```bash
-  helm search prometheus
+  helm repo add stable https://kubernetes-charts.storage.googleapis.com/
   ```
 
 ]
 
+Adding a repo can take a few seconds (it downloads the list of charts from the repo).
+
+It's OK to add a repo that already exists (it will merely update it).
+
 ---
 
-## Install a chart
+## Search available charts
 
-- Most charts use `LoadBalancer` service types by default
+- We can search available charts with `helm search`
 
-- Most charts require persistent volumes to store data
+- We need to specify where to search (only our repos, or Helm Hub)
 
-- We need to relax these requirements a bit
+- Let's search for all charts mentioning tomcat!
 
 .exercise[
 
-- Install the Prometheus metrics collector on our cluster:
+- Search for tomcat in the repo that we added earlier:
   ```bash
-  helm install stable/prometheus \
-         --set server.service.type=NodePort \
-         --set server.persistentVolume.enabled=false
+  helm search repo tomcat
+  ```
+
+- Search for tomcat on the Helm Hub:
+  ```bash
+  helm search hub tomcat
   ```
 
 ]
 
-Where do these `--set` options come from?
+[Helm Hub](https://hub.helm.sh/) indexes many repos, using the [Monocular](https://github.com/helm/monocular) server.
 
 ---
 
-## Inspecting a chart
+## Charts and releases
 
-- `helm inspect` shows details about a chart (including available options)
+- "Installing a chart" means creating a *release*
+
+- We need to name that release
+
+  (or use the `--generate-name` to get Helm to generate one for us)
 
 .exercise[
 
-- See the metadata and all available options for `stable/prometheus`:
+- Install the tomcat chart that we found earlier:
   ```bash
-  helm inspect stable/prometheus
+  helm install java4ever stable/tomcat
   ```
 
-]
-
-The chart's metadata includes a URL to the project's home page.
-
-(Sometimes it conveniently points to the documentation for the chart.)
-
----
-
-## Viewing installed charts
-
-- Helm keeps track of what we've installed
-
-.exercise[
-
-- List installed Helm charts:
+- List the releases:
   ```bash
   helm list
   ```
 
 ]
+
+---
+
+class: extra-details
+
+## Searching and installing with Helm 2
+
+- Helm 2 doesn't have support for the Helm Hub
+
+- The `helm search` command only takes a search string argument
+
+  (e.g. `helm search tomcat`)
+
+- With Helm 2, the name is optional:
+
+  `helm install stable/tomcat` will automatically generate a name
+
+  `helm install --name java4ever stable/tomcat` will specify a name
+
+---
+
+## Viewing resources of a release
+
+- This specific chart labels all its resources with a `release` label
+
+- We can use a selector to see these resources
+
+.exercise[
+
+- List all the resources created by this release:
+  ```bash
+  kuectl get all --selector=release=java4ever
+  ```
+
+]
+
+Note: this `release` label wasn't added automatically by Helm.
+<br/>
+It is defined in that chart. In other words, not all charts will provide this label.
+
+---
+
+## Configuring a release
+
+- By default, `stable/tomcat` creates a service of type `LoadBalancer`
+
+- We would like to change that to a `NodePort`
+
+- We could use `kubectl edit service java4ever-tomcat`, but ...
+
+  ... our changes would get overwritten next time we update that chart!
+
+- Instead, we are going to *set a value*
+
+- Values are parameters that the chart can use to change its behavior
+
+- Values have default values
+
+- Each chart is free to define its own values and their defaults
+
+---
+
+## Checking possible values
+
+- We can inspect a chart with `helm show` or `helm inspect`
+
+.exercise[
+
+- Look at the README for tomcat:
+  ```bash
+  helm show readme stable/tomcat
+  ```
+
+- Look at the values and their defaults:
+  ```bash
+  helm show values stable/tomcat
+  ```
+
+]
+
+The `values` may or may not have useful comments.
+
+The `readme` may or may not have (accurate) explanations for the values.
+
+(If we're unlucky, there won't be any indication about how to use the values!)
+
+---
+
+## Setting values
+
+- Values can be set when installing a chart, or when upgrading it
+
+- We are going to update `java4ever` to change the type of the service
+
+.exercise[
+
+- Update `java4ever`:
+  ```bash
+  helm upgrade java4ever stable/tomcat --set service.type=NodePort
+  ```
+
+]
+
+Note that we have to specify the chart that we use (`stable/tomcat`),
+even if we just want to update some values.
+
+We can set multiple values. If we want to set many values, we can use `-f`/`--values` and pass a YAML file with all the values.
+
+All unspecified values will take the default values defined in the chart.
+
+---
+
+## Connecting to tomcat
+
+- Let's check the tomcat server that we just installed
+
+- Note: its readiness probe has a 60s delay
+
+  (so it will take 60s after the initial deployment before the service works)
+
+.exercise[
+
+- Check the node port allocated to the service:
+  ```bash
+  kubectl get service java4ever-tomcat
+  PORT=$(kubectl get service java4ever-tomcat -o jsonpath={..nodePort})
+  ```
+
+- Connect to it, checking the demo app on `/sample/`:
+  ```bash
+  curl localhost:$PORT/sample/
+  ```
+
+]
\ No newline at end of file