Migrations / Database Version like Marabunta / Anthem?

[mileo]

Hi,

Currently at @kmee we are used to using the https://github.com/camptocamp/docker-odoo-project that some powerfull tools like:

• https://github.com/camptocamp/marabunta
• https://github.com/camptocamp/anthem

Marabunta helps a lot the migration process, you can edit your migration.yml file and every Odoo start the init script check the current version of the database and run the required migration scripts to update the dabatase.

I'm sure that some features of Anthem can be replaced by click-odoo, however with the little I've studied about doobda and its tools I still haven't seen a practical way of dealing with migrations like Marabunta.

Has this not been implemented yet? (Doobda is very good, congratulations!!!!)

[pedrobaeza]

Hi, Luis,

We have never felt the need to add even more tools to such task, as it only increases the complexity of the architecture with no very high value, as well as requiring to learn another syntax for doing things.

We use the same Python and ORM syntax that we are used to for programming migration scripts. What are the possible options:

1. Our preferred one, which is to use the own Odoo migration machinery, bumping module manifest version, and programming migration scripts. You can check briefly how they work in this old reference (but still valid): https://odoo-development.readthedocs.io/en/latest/maintenance/data-migration.html, or a talk I gave at Odoo Italian days (but without showing the slides): https://www.youtube.com/watch?v=KbuHM8Qr5Pw.

   This way, we streamline all the things to do inside the same code that we are handling for our modules. This serves both for changes in the middle of a major version, or for migrating between major versions.

2. When doing migrations between major versions, some manual tweaks (in the form of SQL queries) may be needed, so with a bash script for both executing the commands to do the upgrade (basically the DB dump+restore, filestore duplication, and -u all command), and any of these tweaks. Example: docker-compose run --rm -l traefik.enable=false odoo psql -c "DELETE FROM ir_ui_view WHERE id=15".

3. You can also run stored scripts in Python language + ORM using click-odoo for executing them with a similar syntax to 2: docker-compose run --rm -l traefik.enable=false odoo click-odoo ./script.py, but we are not using this sincerely, having the option 1 that is more streamlined.

[mileo]

Hi, @pedrobaeza

Thanks for your answer, my replica took a while as I was studying the project in my spare time...

At KMEE we are used to deploying Odoo on a k8s cluster, this makes us need more complex migration strategies, as we cannot update or install a module by commands like:

• invoke install -m web_responsive or any other related alias (odoo-bin -i or click-odoo)

We usually create update strategies with Marabunta, I'll put an example below:

migration:
  options:
    install_command: odoo
  versions:
    - version: setup
      operations:
        post:
          - anthem songs.install.base::main #configure main company and currency
      addons:
        upgrade:
          - disable_odoo_online
          - remove_odoo_enterprise
          - mail_debrand
          - auth_admin_passkey
          - web_responsive
          - support_branding
    - version: 0.0.1
      operations:
        post:
          - anthem songs.install.config::config_crm
      addons:
        upgrade:
          - crm
    - version: 0.0.2
      addons:
        upgrade:
          - crm_lead_code
          - crm_industry
      operations:
        post:
          - anthem songs.install.config::import_industry_csv
    - version: 0.0.3
           addons:
        upgrade:
          - crm_new_feature_XYZ

Before Odoo starts it determines which version it is installed and which steps must be taken to go to the next version, steps like:

• modules to configure;
• modules to install;
• modules to upgrade;
• modules to remove;
• etc.

So after doing all the programmed steps, Odoo turns off and on again, releasing the http interface to the user. And that happens by deploying a new registry image that processes the migrations.yaml file

[mileo]

FYC https://github.com/camptocamp/docker-odoo-project/blob/master/bin/docker-entrypoint.sh#L119-L134

[pedrobaeza]

It doesn't matter you deploy with k8s, as similar integration tools as the one I mentioned are available for doing the stuff, but adding another framework like marabunta for such things is overkill IMO. You can anyway do it if you think it's the way to go.