Oduflow namespace and control repository

Oduflow uses oduflow.sh for client hosting. Configure the delivery repository and branch for the installation.

Core version 19.0.6.0.1 discovers the previous model namespace from installed XML ownership, then uses the pinned official Odoo upgrade utilities to rename models, tables, many-to-many relations, fields and indirect references. It retains record IDs, foreign keys, ACLs, XML ownership and encrypted values. The queue channel and serialized recordsets migrate with the models. All installed provider and integration modules must be upgraded in the same run.

Before deployment, take a database/filestore backup, drain running queue jobs and supply the unchanged encryption key under ODUFLOW_ENCRYPTION_KEY. Rename other deployment environment keys to the ODUFLOW_ prefix while preserving their values. Apply through the target Oduflow MCP, including module upgrades. Verify record IDs/counts, secret decryption, the effective queue configuration, and a harmless real queued operation.

Immutable provisioning snapshots, provider IDs and dispatch receipts are audit records, not branding configuration. Do not rewrite them with a text replace: external address changes require reconciliation and fresh verification of the same owned resources. New and unprepared client instances use oduflow.sh. Existing domain cutovers require DNS access, certificates and coordinated VPN endpoint configuration.

Legacy addon-name migration

This procedure applies only to a database that still has the predecessor addon installed. A new control database installs the current modules directly.

1. Back up the database/filestore and retain the existing encryption key.
2. Before loading the new checkout, run scripts/rename-odoo-addon.py in the old Odoo shell with env available and commit its successful transaction. It preserves the installed module record while renaming dependencies and base.module_* XML IDs.
3. Load the new source and upgrade oduflow first. Install oduflow_vultr in a separate operation: delivery can install before upgrading within one pull_and_apply call, which would precede the required ownership migration. Migration 19.0.2.0.0 transfers XML-ID ownership without changing record IDs; the pre-install hook handles remaining legacy metadata on first installation.
4. Verify existing instances, secrets, journals, namespace reservations and prepared addresses, then run the relevant addon tests.

Do not uninstall the old addon as a migration shortcut: uninstall can remove its owned records. Select the procedure by the database's installed history, not by an old deployment report's hostname.

Control master's repository

The master runs a root-owned Git checkout at /srv/oduflow. Credentials, local pillar and durable operation caches stay outside Git, under /etc/oduflow, /etc/salt and /var/cache/salt. A private repository uses a read-only deploy key owned by root; do not store a personal GitHub token in the checkout.

For the first installation, clone the repository into /srv/oduflow, check out the delivery branch, and run scripts/bootstrap-control.sh. For an existing master, preserve its identities, secrets and operation caches before moving paths and applying the new control configuration.

Subsequent updates use:

sudo /srv/oduflow/scripts/update-control.sh --revision COMMIT_SHA
sudo /srv/oduflow/scripts/update-control.sh --revision COMMIT_SHA --apply control_config,control_master

The updater refuses dirty checkouts and non-fast-forward history. It fetches only the selected branch and verifies the requested commit belongs to it. Updating sources does not apply states until --apply is supplied. Salt remains the configuration authority. Keep local configuration and pillar out of the checkout so updates never overwrite deployment secrets.