Support environment variables in odoo.conf

[codebykyle]

Following on from the changes mentioned in:
#538

This also resolves:
#535

and permanently addresses:
#497

[codebykyle]

To test the changes, cd into the 18.0 directory. You can use the included docker-compose.yml to build the docker container and launch a copy of Odoo using these changes.

Eg:

git clone [email protected]:odoo/docker.git
cd docker
gh pr checkout 539
cd 18.0

Then:

docker compose build && docker compose up

[codebykyle]

I'm further testing this.

One thing that I do not like is that if you mount a config file at /etc/odoo/odoo.conf, it will be overwritten once merged on the host machine. This is because the mounted file is the same location as the config file that Odoo uses.

Additionally, the file will be mounted as ubuntu:ubuntu. This means that we need to add Odoo to the ubuntu group via RUN usermod -aG ubuntu odoo.

The ps python script can remain as-is.

There are two ways to address this:

Option 1: Change ODOO_RC to another location

We can use the default /etc/odoo/odoo.conf as the input for envsubst. We update the ODOO_RC env location in the docker file. This will enable these features by default. No existing changes would need to be done for setups mounting the configuration in /etc/odoo/odoo.conf, we would just natively support this

Option 2: Make this feature optional using a config template location

Moving the file into a different file other than /etc/odoo/odoo.conf would make this feature optional. For example, if the user mounts a file at /etc/odoo-docker/odoo.conf, we generate the /etc/odoo/odoo.conf. If there is no file there, we skip this step and do not enable environment variable injection. This would be a default off, optional method of doing this.

[codebykyle]

I've pushed a change to address that issue.

The config file that Odoo now loads is /etc/odoo/odoo_docker.conf, as specified in ODOO_RC in the Dockerfile.

The wait script automatically picked that change up.

This enables this feature by default, and reduces any complexity that would come with template files.

This also is a drop-in replacement for current builds, nothing will need to change for end users to take advantage of this. If the user mounts their config to /etc/odoo/odoo.conf, under the hood, it will automatically be moved to /etc/odoo/odoo_docker.conf as-is.

[codebykyle]

Further testing:

Forgot to add the new environment variables to match the Odoo config values, eg:

DB_HOST as opposed to HOST.

The existing environment variables should continue to work (eg, HOST), but they are mapped to $DB_HOST for consistency.

For example:

    environment:
#      DB_HOST: ${DB_HOST:-db}
      HOST: "testing"

will be merged such that the following:

[options]
db_host = $DB_HOST

results in a correct merge:

However, the DB_HOST , DB_PORT, etc are the ideal settings as they match the config name

[codebykyle]

I tested all the config settings.

The only one that had an issue was osv_memory_age_limit, which has been renamed to transient_age_limit, per the warning generated by Odoo.

2025-02-11 06:33:25,600 1 WARNING ? py.warnings: /usr/lib/python3/dist-packages/odoo/tools/config.py:603: DeprecationWarning: The 'osv_memory_age_limit' option found in the configuration file is a deprecated alias to 'transient_age_limit', please use the latter.

I've pushed a change to rename that option.

I think most major development efforts with this are done. Some testing should be performed by someone other than me. All my needs are more or less met. I think one minor change I may make is to make the timeout configurable by env, but that isn't critical for my use-case.

If we want to continue with this method, I can get some documentation up for the settings. Please let me know if anyone has any feedback on this.

[codebykyle]

Sorry, I figured if we're going to do it, may as well go all the way with it. I couldnt help but adding the timeout setting and switching things over to pg_isready.

Pushed a patch to support pg_isready in the psql wait script.

pg_isready is actually what we want here. I do not think we should move everything into bash, I still think the python script is the best solution to this problem, but we can call pg_isready from python. This lets us parse the generated config file (or if one is provided by the user) for the database details. This is troublesome in bash, where Python there is native support.

pg_isready does not require any database to connect to. It simply returns if the server is accepting connections. It does not require authentication.

Odoo supports domain and sub-domain driven database selection. In order to get truly multi-tenant behavior out of this, we must not actually specify a database to connect to when waiting for psql to come up:

https://www.odoo.com/documentation/18.0/administration/on_premise/deploy.html#dbfilter

Using pg_isready allows us to do this.

Additionally, I added an environment variable for the timeout for pg_isready. You can configure the allowed timeout with PSQL_WAIT_TIMEOUT which defaults to 30. I documented it in the docker-compose.yml file.

[amh-mw]

Sorry, I figured if we're going to do it, may as well go all the way with it.

AFAIK this repository has no maintainer yet receives bi-weekly updates from some internal Odoo SA build process. I have never seen a PR get merged.

[codebykyle]

That isn't surprising and more or less checks out. This repository as it is does not support many features of Odoo, specifically around multi-tenancy. I'll leave these changes here, as they work, and anyone can use them, or I will create my own container with these features and publish that to Dockerhub, whatever that is worth.

These are necessary features, especially if you are selling or hosting Odoo on cloud providers aside from Odoo.sh.

If the OCA is interested, maybe we can transfer it to them.

[codebykyle]

I have submitted a patch to fix a potential race condition with ps_isready on initial startup. That should be resolved.

This will likely be the last PR update I submit here if this repository is not maintained. Having checked the commit history, I believe you are correct @amh-mw

I actually do need this container to be working this way, so I have moved my efforts over to a new repository.

It is available here. Image name will be adomi-io/odoo

I'll accept PRs if anyone would like to contribute.

I also switched the image over to Alpine Linux and split this up into a multi-layer build process for things like wkhtmltopdf, node, and source management, so that we're able to actually automate the build process with Github actions, as opposed to some internal build process over at Odoo. The resulting docker image is very lightweight by comparison to the full Ubuntu image this repo is pulling.

This should let us setup a mirror of the Odoo Github repo so we are not dependent on some internal build process to submit secret updates that occasionally break enterprise. I'm happy to contribute those changes back to this repository but it doesnt seem like that is going to be accepted, so why bother.

In the meantime, the changes submitted here should work if anyone wants these features. Let me know if anyone out there in the void ends up using this.

Thanks folks.

Edit:

I have setup that package with the changes listed above. If you want access to these features while this PR is pending, they are available at the linked repository. Still doing some testing on it, help is welcomed, but I setup a GitHub action to automatically build the corresponding Odoo branches on a schedule. This will take daily snapshots of Odoo, so no weird back-end internal build process at Odoo corporate.

Images are available here

I know Odoo docker containers are a dime-a-dozen, but this is my drop in the ocean. I will maintain this for the foreseeable future. I use Odoo images every day.

If you want to track a specific Odoo branch:

• Create a branch with the same name as the branch in the Odoo repository.

It will automatically build a daily container with the corresponding Odoo version.

I will include some details in the readme on how to build an enterprise version of this container when I have time, and document some of the upgrades I made.