We were assuming the disk setup would, which is counter intuitive.

mostly to note down the parts that will go away

we're still on track though

This is in preparation to communicating to service admins.

The rationale of this is that we want to speed up the upgrade process
and not let the upgrade wait for operator wandering away in another
distraction. Inversely, it allows operators to exactly do other things
instead of just staring at the terminal, waiting for the process to
complete.

This assumes users either like bell noises or have turned them off in
their terminal. In my case, the terminal is set to send a "urgent"
signal to the window manager when it receives a "bell", using this
Xresources configuration:

    URxvt.urgentOnBell:  true
    XTerm*bellIsUrgent:  true
    XTerm*visualBell: false

In i3 with i3status (and py3status), the affected workspace gets a
nice red background, telling me the upgrade is waiting for my input.

This reduces the clutter of recording files left lying around.

metrics policy was announced here https://trac.torproject.org/projects/tor/ticket/32998#comment:2

A glossary doesn't belong in the tutorial, which expects the user to
know nothing of the service. That belonds in the Howto section, where
we expect to learn a little more about the service before doing things.

I added that TODO based on a misunderstanding of the function of the
private network between the Ganeti nodes. It's not there to provide a
private network between *instances*, but really just the nodes, for
DRBD and Ganeti traffic.

So it makes no sense to allocate private IPs to the instances in that context.

We remove the `gnt-node list` command because it's included in the other.

The rationale is that this part is more rarely used and definitely
more complex than a Howto.