errores migrando de odoo 8 a odoo 9 con openupgrade

[Pau Aliagas]

Hola.

Estoy migrando a v9 con openupgrade con el script automático.

Las instrucciones que sigo son estas:
https://doc.therp.nl/openupgrade/

Y las de ejecutar el script estas:
https://doc.therp.nl/openupgrade/migrate.py.html

Las versione que aparecen en migration.log:
Running migration [>9.0.1.3] pre-migration
base: pre-migration script called with version 8.0.1.3

He tenido que eliminar de la base de datos los siguientes módulos porque la migración fallava:
account_auto_fy_sequence
account_cancel
account_bank_statement_import

Espero poder instalar algo parecido de los dos primeros si acabo la migración :)

Ahora me falla con este error:
2018-02-12 17:53:32,755 22269 ERROR futini-2018_migrated openerp.modules.registry: Failed to load registry
Traceback (most recent call last):
  File "/var/tmp/openupgrade/9.0/server/openerp/modules/registry.py", line 390, in new
    openerp.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/var/tmp/openupgrade/9.0/server/openerp/modules/loading.py", line 408, in load_modules
    force, status, report, loaded_modules, update_module, upg_registry)
  File "/var/tmp/openupgrade/9.0/server/openerp/modules/loading.py", line 299, in load_marked_modules
    loaded, processed = load_module_graph(cr, graph, progressdict, report=report, skip_modules=loaded_modules, perform_checks=perform_checks, upg_registry=upg_registry)
  File "/var/tmp/openupgrade/9.0/server/openerp/modules/loading.py", line 147, in load_module_graph
    models = registry.load(cr, package)
  File "/var/tmp/openupgrade/9.0/server/openerp/modules/registry.py", line 173, in load
    model = cls._build_model(self, cr)
  File "/var/tmp/openupgrade/9.0/server/openerp/models.py", line 623, in _build_model
    original_module = pool[name]._original_module if name in parents else cls._module
  File "/var/tmp/openupgrade/9.0/server/openerp/modules/registry.py", line 88, in __getitem__
    return self.models[model_name]
KeyError: 'account.tax.code'


Mirando el migrations.log veo que antes renombra table account_tax_code: renaming to account_tax_group

Copio la parte de log donde esto ocurre:

2018-02-12 17:52:38,472 22269 INFO futini-2018_migrated openerp.modules.migration: module account: Running migration [>9.0.1.1] pre-migration
2018-02-12 17:52:38,472 22269 INFO futini-2018_migrated openerp.modules.migration: module account: Running migration [>9.0.1.1] pre-migration
2018-02-12 17:52:38,474 22269 INFO futini-2018_migrated OpenUpgrade: account: pre-migration script called with version 8.0.1.1
2018-02-12 17:52:38,479 22269 INFO futini-2018_migrated OpenUpgrade: table account_statement_operation_template: renaming to account_operation_template
2018-02-12 17:52:38,479 22269 INFO futini-2018_migrated OpenUpgrade: table account_tax_code: renaming to account_tax_group
2018-02-12 17:52:38,480 22269 INFO futini-2018_migrated OpenUpgrade: table account_statement_operation_template_id_seq: renaming to account_operation_template_id_seq
2018-02-12 17:52:38,480 22269 INFO futini-2018_migrated OpenUpgrade: table account_tax_code_id_seq: renaming to account_tax_group_id_seq
2018-02-12 17:52:38,480 22269 INFO futini-2018_migrated OpenUpgrade: table account_account, column type: renaming to openupgrade_legacy_9_0_type

¿Como puedo solucionar este problema?

[ゴイコエチェアイボン]

Hola,

yo estuve el año pasado peleándome con el script de migración para pasar de 8>9>10. Me encontré con diversos errores en la base de datos, campos que tenían NULL y ya no podían ser NULL, valores por defecto que no existían, y cosas así.

Después de resolverlos conseguí hacer un circuito completo sin errores, pero el resultado no fue muy bueno. Cosas como clientes, proveedores, usuarios y este tipo de tablas estaban bien, pero las relaciones no quedaron nada bien. Recuerdo que por ejemplo, las cuentas bancarias estaban, pero habían perdido su propietario, toada la parte de plazos de pago y formas de pago también se había desconfigurado.

Finalmente opte por el proceso de exportación/importación de los datos de las tablas base, y comenzar con una base de datos limpia.

[Jose R. Prieto]

En mi opinión, pocas cosas conozco mejores que esto:

https://community.hds.com/docs/DOC-1009855

https://www.adictosaltrabajo.com/tutoriales/kettle/

Para volúmenes pequeños, con CSVs puedes apañar... Pero para cosas ya "grandes", hay que plantearse cosas de ese tipo (o bien scripts de migración, claro)

Saludos.

--
Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-users+unsub...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Jose R. Prieto about.me/joserprieto

talk...@joserprieto.es

[Pedro Manuel Baeza Romero]

Yo creo que exportar/importar CSV es un atraso teniendo OpenUpgrade tan avanzado para esas versiones.

Simplemente, hay que olvidarse de ese script de migración (migrate.py), y realizar un simple --update all ejecutando el servidor OpenUpgrade en la versión N+1 (v9), teniendo la BD y el filestore de la versión N (v8). Es lo que hace ese script al final, pero con ciertos automatismos que abstraen ciertas cosas que son los detalles que pueden fallar.

Quiero hacer un tutorial de cómo migrar con nuestra imagen Docker, pero por carga de trabajo es algo que no podré hacer hasta dentro de un mes o así.

Ahora bien, el problema es si tu BD de la versión N (en este caso, v8) está hecha un cristo, no va a ver quien la migre, porque hay que empezar por arreglar eso. A ver, para empezar, hay que hacer un --update all en la propia v8 con la última versión de código de todo. Por aquí algunos han contado que no hacen update desde hace años porque "les daba un error". Eso me parece una auténtica aberración y con eso que no esperen poder migrar.

Claro, la exportación/importación CSV como es borrón y cuenta nueva, no adolece de esos problemas, pero vas a perder un montón de información que yo personalmente para mi negocio no lo permitiría.

Un saludo.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-users+unsubscribe...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Jose R. Prieto about.me/joserprieto

talk...@joserprieto.es

[Pau Aliagas]

On Tuesday, February 13, 2018 at 1:29:02 PM UTC+1, Pedro Manuel Baeza Romero wrote:

Yo creo que exportar/importar CSV es un atraso teniendo OpenUpgrade tan avanzado para esas versiones.

Simplemente, hay que olvidarse de ese script de migración (migrate.py), y realizar un simple --update all ejecutando el servidor OpenUpgrade en la versión N+1 (v9), teniendo la BD y el filestore de la versión N (v8). Es lo que hace ese script al final, pero con ciertos automatismos que abstraen ciertas cosas que son los detalles que pueden fallar.

No he sabido encontrar como hacer esto que explicas. He leído bastantes cosas pero de openupgrade sólo he visto el script. Lo más parecido era vuestro entorno scaffolding pero he sido incapaz ni de arrancarlo (como he puesto en otro thread anterior).
 

Quiero hacer un tutorial de cómo migrar con nuestra imagen Docker, pero por carga de trabajo es algo que no podré hacer hasta dentro de un mes o así.

Si me das alguna indicación por lo menos compartiré las instruccioes y los problemas que me encuentre.
Tengo el hándicap que no sé casi nada de Odoo, conozco docker, postgres, python, git, sistemas.... pero en odoo me pierdo.
 

Ahora bien, el problema es si tu BD de la versión N (en este caso, v8) está hecha un cristo, no va a ver quien la migre, porque hay que empezar por arreglar eso. A ver, para empezar, hay que hacer un --update all en la propia v8 con la última versión de código de todo. Por aquí algunos han contado que no hacen update desde hace años porque "les daba un error". Eso me parece una auténtica aberración y con eso que no esperen poder migrar.

Yo ejecuto --update-all cada vez que actualizo el git. De hecho está al día y no tendría porque estar mal ya que sólo he instalado los módulos para hacer la contabilidad y siempre del git. A pesar de todo el script ha ido fallando y yo eliminando módulos para ver si acababa.

Claro, la exportación/importación CSV como es borrón y cuenta nueva, no adolece de esos problemas, pero vas a perder un montón de información que yo personalmente para mi negocio no lo permitiría.

Coincido contigo, no tiene sentido si se puede evitar.

Como siempre, muchas gracias a todos por vuestra ayuda.
Pau

[Jose R. Prieto]

+1000, Pedro.

¿Actualizar el ERP?

¿Qué es eso?

Etc etc....

Supongo que con la imagen Docker, jugando con:

command:
	- odoo
	- --workers=0
	# XXX Odoo v8 has no `--dev` mode; Odoo v9 has no parameters
	- --dev=reload,qweb,werkzeug,xml,wdb

Bueno; por pasos

1) Se monta / configura el docker-scaffolding para versión N (con los módulos necesarios, se entiende).

2) Se importa la DDBB de la versión N que se desea migrar.

3) Sin tocar el volumen Docker, se modifican los YAML; el repos.yaml para coger la versión de OpenUpgrade, el .env para coger la versión nueva de Odoo (N+1), el Dockerfile para ídem (N+1), -y no se si me dejo algún fichero más).

4) Se reconstruye la imagen.

5) Se vuelven a descargar los repos etc para la versión N+1

6) Se arranca la nueva imagen, jugando con los parámetros del command, para que haga el Upgrade.

Si necesitas ayuda, dime, y vemos como puedo ayudarte.

Saludos.

[Pau Aliagas]

Te respondo por privado y al final publico un HOWTO con el detalle de los pasos seguidos, si  te parece bien, para que quede para todos.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-users+unsub...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Jose R. Prieto about.me/joserprieto

talk...@joserprieto.es

--
Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-users+unsub...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-users+unsub...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Jose R. Prieto]

Disculpa...

Le decía a Pedro si necesitaba ayuda para hacer el tuto con su docker-base...

Pero, así a grandes rasgos..

# add custom Dockerfile
mkdir custom
echo > custom/Dockerfile << EOF
FROM tecnativa/odoo-base
MAINTAINER Me <linu...@gmail.com>
EOF

¿Para qué haces eso?

Ahí, lo que tienes que tener cuidado es que el docker base sea el mismo tag (versión) que tengas definido en el .env file

# XXX Base version must match $ODOO_VERSION in .env file

FROM tecnativa/odoo-base:9.0

Por ejemplo, ese, ahí tengo una 9.0 en el .env.

¿Y esto otro?

# make sure permissions are right
chown -R odoo:odoo odoo/auto
chmod -R ug+rwX odoo/auto
# put it in .bashrc
export UID GID="$(id -g $USER)" UMASK="$(umask)"
# add user to docker group (otherwise ti can't connect to docker's socket)
useradd -a -G docker odoo

yo utilizo mi usuario local, que está agregado al grupo de docker; vamos, tienes que tener un usuario que tenga permisos para ejecutar docker, ni más, ni menos.

Después, veo este error:

odoo_1  | INFO:docker-odoo-base:Linking all addons from /opt/odoo/custom/src/addons.yaml in /opt/odoo/auto/addons
odoo_1  | Traceback (most recent call last):
odoo_1  |   File "/opt/odoo/common/entrypoint.d/40-addons-link", line 26, in <module>
odoo_1  |     os.symlink(src, dst)

Me da a mi que tienes algo mal en el ./odoo/custom/src/addons.yaml, o en el ./odoo/custom/src/repos.yaml;

Los pasos, muy resumidos, son estos:

## Simple steps to use the Tecnativa/docker-odoo-base.

### Init the project.

```

git clone -b scaffolding https://github.com/Tecnativa/docker-odoo-base.git myproject

cd myproject

ln -s devel.yaml docker-compose.yml

chown -R $USER:1000 odoo/auto

chmod -R ug+rwX odoo/auto

export UID="$(id -u $USER)" GID="$(id -g $USER)" UMASK="$(umask)"

docker-compose build --pull

docker-compose -f setup-devel.yaml run --rm odoo

docker-compose up.

```

 

Que son:

1) Clonas el scaffolding al directorio que quieras

2) Vas a ese directorio

3) creas enlace simbólico del archivo devel.yaml a docker-compose-yml; esto te lo puedes ahorrar si ejecutas docker-compose con la opción -f (file)

4) das permisos a tu usuario sobre los directorios

5) exportas variables de entorno (a mi esto en Linux Mint / Ubuntu no me tira, pero tampoco me da problmeas)

Ahora viene la parte interesante...

6) en el docker build, lo que haces es crearte una imagen propia, a partir de la imagen base de Tecnativa, y de la configuración que tengas en los archivos que hay en ./odoo/custom/dependencies; que son varios, y hacen diferentes cosas; mírate el Dockerfile del base, para saber qué hacen exactamente. Pero, muy en resumen, cogen las dependencias que tengas definidas en cuanto a paquetes apt, paquetes npm, paquetes pip.. Y las instala.

7) ahora, ejecuta una instancia de la imagen odoo que has creado, y lo único que haces es clonar los repositorios que tengas definidos en el ./odoo/custom/src/repos.yaml; que es un archivo de git-aggregator, que es lo que usa para ese clonado.

8) arranca todo el stack; no recuerdo si los enlaces simbólicos a los módulos que tienes definidos ./odoo/custom/src/addons.yaml los crea en el arranque, o los crea en el paso anterior; mira los scripts que tiene el docker base.

Personalmente, yo lo tengo en un archivo Makefile, y después hago "make ..."; algo así:

build:

    docker-compose build --pull

setup:

    docker-compose -f setup-devel.yaml run --rm odoo

run:

    docker-compose up -d

up: run

down:

    docker-compose down

start:

    docker-compose start

stop:

    docker-compose stop

pause:

    docker-compose pause

tail-odoo:

    docker-compose logs -f --tail 10 odoo

tail-services:

    docker-compose logs -f --tail 10

inspect-db:

    docker-compose run --rm odoo psql

restart-odoo:

    docker-compose restart -t0 odoo

restart-odoo-prod:

    docker-compose restart odoo https

default: run

y después, hago make build, make up, make....; para mi es más cómodo, pero bueno, para gustos, los colores.

¿Por qué no te crea la base devel?; pues, no lo tengo muy claro; prueba a usar el docker de forma "estándar"; y una vez te arranque, pues ya puedes empezar a plantearte más cosas.

Como comentario, en el devel.yaml (que es el docker-compose.yaml, que has hecho un ln), tienes estas variables de entorno:

environment:

ADMIN_PASSWORD: admin

PGDATABASE: "testpsodoo"

PYTHONOPTIMIZE: ""

# You want demo data for development

WITHOUT_DEMO: "false"

Una es el nombre de la base de datos; yo, cuando hago una instalación nueva, borro la que crea por defecto, y creo una nueva, para que me salte el asistente; pero tú ahí lo que puedes hacer es borrar la que te crea por defecto (por defecto tiene de nombre "devel", si no recuerdo mal), importar la exportación del Odoo que quieres migrar, ponerle el nombre que quieras, y ese mismo nombre ponerlo ahí.

Eso te lo va a guardar en un volumen docker; si te fijas, en ese mismo archivo:

volumes:

filestore:

db:

(al final); y en el servicio odoo, tienes:

volumes:

- ./odoo/custom:/opt/odoo/custom:ro,z

- ./odoo/auto/addons:/opt/odoo/auto/addons:rw,z

Que son directorios de "fuera", vamos, se "ven" directamente en el filesystem (eso es una cuestión al gusto, puedes clonar en un volumen docker, que es la práctica recomendada, además).

Pero el servicio db:

db:

hostname: "db.testpsodoo.odoo.localhost"

container_name: "testpsodoo_odoo_db"

extends:

file: common.yaml

service: db

networks:

testpsodoo_odoo_demo_network:

ipv4_address: 172.21.107.102

extiende de common.yaml:

db:

image: postgres:${DB_VERSION}-alpine

environment:

POSTGRES_USER: "$DB_USER"

POSTGRES_PASSWORD: "$DB_PASSWORD"

volumes:

- db:/var/lib/postgresql/data:z

fíjate; usa el filestore db, que es un volumen docker.

en el caso del servicio odoo, que extiende también de common.yaml, tienes, en el common.yaml:

odoo:

build:

context: ./odoo

args:

CONFIG_BUILD: "false"

environment:

ADMIN_PASSWORD: "$ODOO_ADMIN_PASSWORD"

PGPASSWORD: "$DB_PASSWORD"

PGUSER: "$DB_USER"

PROXY_MODE: "$ODOO_PROXY_MODE"

PYTHONOPTIMIZE: 2

tty: true

volumes:

- filestore:/var/lib/odoo:z

labels:

traefik.docker.network: "inverseproxy_shared"

traefik.enable: "true"

traefik.frontend.passHostHeader: "true"

traefik.longpolling.port: "8072"

traefik.port: "8069"

Usa el volumen docker "filestore", para guardar archivos, etc.

todos los labels traefik, son para usar con el servidor web traefik (bueno, más bien es un proxy inverso exclusivamente); si quieres usarlo con nginx u otros, todo eso no te vale para nada.

Como no veo nada que sea "delicado" o "sensible" en lo que publicas, y lo que pongo, puede ser de ayuda a más gente, lo voy a publicar directamente en el grupo.

Saludos.

2018-02-14 12:37 GMT+01:00 Pau Aliagas <linu...@gmail.com>:

On Tuesday, February 13, 2018 at 7:16:48 PM UTC+1, Jose R. Prieto wrote:

+1000, Pedro.

¿Actualizar el ERP?

¿Qué es eso?

Etc etc....

Supongo que con la imagen Docker, jugando con:

command:
	- odoo
	- --workers=0
	# XXX Odoo v8 has no `--dev` mode; Odoo v9 has no parameters
	- --dev=reload,qweb,werkzeug,xml,wdb

Bueno; por pasos

1) Se monta / configura el docker-scaffolding para versión N (con los módulos necesarios, se entiende).

2) Se importa la DDBB de la versión N que se desea migrar.

3) Sin tocar el volumen Docker, se modifican los YAML; el repos.yaml para coger la versión de OpenUpgrade, el .env para coger la versión nueva de Odoo (N+1), el Dockerfile para ídem (N+1), -y no se si me dejo algún fichero más).

4) Se reconstruye la imagen.

5) Se vuelven a descargar los repos etc para la versión N+1

6) Se arranca la nueva imagen, jugando con los parámetros del command, para que haga el Upgrade.

Si necesitas ayuda, dime, y vemos como puedo ayudarte.

Necesito bastante ayuda porque ni tan sólo puedo poner en marcha la base de datos de devel.

Te explico los pasos seguidos, básicamente los del README:

# clone repo
git clone -b scaffolding https://github.com/Tecnativa/docker-odoo-base.git docker-odoo-base

# make sure permissions are right
chown -R odoo:odoo odoo/auto
chmod -R ug+rwX odoo/auto

# put it in .bashrc
export UID GID="$(id -g $USER)" UMASK="$(umask)"

# add user to docker group (otherwise ti can't connect to docker's socket)
useradd -a -G docker odoo

# setup devel env
cd docker-odoo-base
ln -s devel.yaml docker-compose.yml
docker-compose build --pull

# add custom Dockerfile
mkdir custom
echo > custom/Dockerfile << EOF
FROM tecnativa/odoo-base
MAINTAINER Me <linu...@gmail.com>
EOF

# in devel mode we have to download code ourselves
# src/repos.yaml has the repos to download from
docker-compose -f setup-devel.yaml run --rm odoo

# run project
docker-compose up

Y ya me falla porque no puede crear una base de datos devel.

Attaching to dockerodoobase_smtp_1, dockerodoobase_wdb_1, dockerodoobase_db_1, dockerodoobase_odoo_1
smtp_1  | 2018/02/14 11:36:06 Using in-memory storage
smtp_1  | 2018/02/14 11:36:06 [SMTP] Binding to address: 0.0.0.0:1025
smtp_1  | 2018/02/14 11:36:06 Serving under http://0.0.0.0:8025/
db_1    | LOG:  database system was shut down at 2018-02-11 12:18:00 UTC
smtp_1  | [HTTP] Binding to address: 0.0.0.0:8025
smtp_1  | Creating API v1 with WebPath:
smtp_1  | Creating API v2 with WebPath:
db_1    | LOG:  MultiXact member wraparound protections are now enabled
db_1    | LOG:  database system is ready to accept connections
db_1    | LOG:  autovacuum launcher started
odoo_1  | INFO:docker-odoo-base:Waiting until postgres is listening at db...
db_1    | FATAL:  database "devel" does not exist
odoo_1  | WARNING:docker-odoo-base:Attempt to install unaccent in devel@db failed with this message: psql: FATAL: database "devel" does not exist
odoo_1  | INFO:docker-odoo-base:Linking all addons from /opt/odoo/custom/src/addons.yaml in /opt/odoo/auto/addons
odoo_1  | Traceback (most recent call last):
odoo_1  |   File "/opt/odoo/common/entrypoint.d/40-addons-link", line 26, in <module>
odoo_1  |     os.symlink(src, dst)
odoo_1  | OSError: [Errno 13] Permission denied
odoo_1  | Traceback (most recent call last):
odoo_1  |   File "/opt/odoo/common/entrypoint", line 28, in <module>
odoo_1  |     subprocess.check_call(command)
odoo_1  |   File "/usr/lib/python2.7/subprocess.py", line 540, in check_call
odoo_1  |     raise CalledProcessError(retcode, cmd)
odoo_1  | subprocess.CalledProcessError: Command '/opt/odoo/common/entrypoint.d/40-addons-link' returned non-zero exit status 1
dockerodoobase_odoo_1 exited with code 1
wdb_1   | [E 180214 11:36:13 ioloop:638] Exception in callback functools.partial(<function wrap.<locals>.null_wrapper at 0x7f35cd8a3400>, HTTPResponse(_body=None,buffer=None,code=599,effective_url='https://pypi.python.org/pypi/wdb.server/json',error=gaierror(-3, 'Try again'),headers=<tornado.httputil.HTTPHeaders object at 0x7f35cd8a1ef0>,reason='Unknown',request=<tornado.httpclient.HTTPRequest object at 0x7f35cd8a17f0>,request_time=5.01943302154541,time_info={}))
wdb_1   |     Traceback (most recent call last):
wdb_1   |       File "/usr/local/lib/python3.6/site-packages/tornado/ioloop.py", line 605, in _run_callback
wdb_1   |         ret = callback()
wdb_1   |       File "/usr/local/lib/python3.6/site-packages/tornado/stack_context.py", line 277, in null_wrapper
wdb_1   |         return fn(*args, **kwargs)
wdb_1   |       File "/usr/local/lib/python3.6/site-packages/wdb_server/__init__.py", line 337, in callback
wdb_1   |         info = json.loads(response.buffer.read().decode('utf-8'))
wdb_1   |     AttributeError: 'NoneType' object has no attribute 'read'

Hasta aquí he llegado.

Muchas gracias
Pau

[YusufSalahAdDin]

Yo tengo el problema este con la base de datos:

 psql: FATAL:  database "odoo" does not exist

Tengo la versión 11 y el problema es provocado por el usuario por defecto para postgres: odoo.

Resulta que postgres genera una base de datos por defecto para el usuario creado; esto implica tener otra base de datos ocupando espacio(si no queremos trabajar en esta misma) y que puede generar una advertencia(odoo busca una estructura compatible en esa base de datos, y como no la encuentra, generar una advertencia SQL) que se soluciona instalando el módulo (todos los módulos) base en esa base de datos, de nuevo, ocupando espacio; por tal motivo yo elimino esa base de datos, y al reiniciar el servidor, pues Odoo intenta acceder a esa base de datos por defecto en lugar de ingresar la base de datos correcta por defecto.

Como resolver este problema?

Mi servidor corre en docker en local.