v3.1.0 — More than one Odoo per machine

Until now the installer assumed it was alone on the machine: every artifact it created was named after the Odoo version, so two installations of the same version collided on the user, the role, the database, the unit and the config file. From 3.1.0 an installation can be named, and the name qualifies everything it owns.

sudo invok --instance cliente-x --port 8169   # a second instance, beside the first
sudo invok list                               # what this machine carries
sudo invok rollback --instance cliente-x      # undo just that one
sudo invok rollback --all                     # undo them all, shared artifacts last

What is new

• --instance <name> (or ODOO_INSTANCE in a .env) names an installation. The name qualifies the system user, the PostgreSQL role, the database, the service unit, the install directory, the config file, the filestore and the helper command — so two instances share nothing but the machine. The name is validated against the intersection of the five grammars it ends up in.
• invok list — the instances installed here, their state, database and directory.
• invok rollback --instance <name> and --all. Removing one instance leaves in place whatever the others are standing on — /opt/odoo, the system packages, the PostgreSQL cluster, wkhtmltopdf, nginx — and says so; no package is purged. That instance's manifest is kept as the record of who owns those, so the last removal can still take them away. --all does the two passes in the right order.
• Two ports per instance. Odoo's longpolling port used to be hardwired to 8072, so two instances wrote the same number and fought over one socket the moment either ran with more than one worker. It is now derived from --port (+3), overridable with --gevent-port / ODOO_GEVENT_PORT, and checked against the ports the other manifests claim — even when nothing is listening on them, which with the default configuration is exactly the case.
• nginx: each vhost gets its own upstreams and its own longpolling port. Two instances behind one proxy used to make nginx -t fail with a duplicate upstream.
• The instance helper (odoo, odoo-cliente-x) gains list and logs, and status now shows every Odoo service on the machine, marking the one that helper drives. Every verb that starts or stops still acts on its own instance alone.

Fixes

Three of these predate this release and were found by running it, not by reading:

• the network timeout killed the shell, not the worker. These commands run through sudo, so killing the child left git alive holding the pipes: the timeout error, already decided, was never reported and an installation could sit for minutes without a line of log — indistinguishable from having no timeout at all.
• the tarball fallback could never succeed. It was downloaded into /tmp and handed to the Odoo user, and creating somebody else's file in a sticky world-writable directory is refused by the kernel, root included. Nobody had noticed: a fallback only runs when the clone has already failed.
• a step that failed halfway was not undone. It had usually created something already, and that stayed on disk — which kept /opt/odoo alive through the rollback and made every later run find it "pre-existing".
• a dropped package download is now asked again (three attempts). A mirror closing one connection out of twenty-five used to cost a whole installation. A package that does not exist is not retried: it would answer the same way every time.
• the home's original mode is restored alongside its owner; the rollback report no longer calls the shared root a leftover when it was kept on purpose; and the refusal on an existing installation now names --instance among the ways forward.

Upgrading from 3.0.0

• Nothing changes for a single installation. Whoever does not ask for an instance keeps every path, unit, user and manifest exactly as before — byte for byte. Manifests written by earlier versions stay readable, and instances installed by them stay removable.
• A manifest written before 3.1.0 is read as claiming the 8072 longpolling port, which is what those installations really bind.
• The instance helper is rewritten at every installation, so an existing instance gains list and logs the next time it is installed.

Getting it

Static binary, no runtime to install first — .tar.gz (any distro), .deb, .rpm, each with its .sha256, or cargo install invok. Commands in the README; the packages are invok_3.1.0-1_amd64.deb and invok-3.1.0-1.x86_64.rpm.

Verified on Ubuntu 22.04/24.04, Debian 11/12 and Fedora 41/44, with a CI job that installs two instances side by side and removes them one at a time.