[IMP] travis2docker: fix permissions and simplify shell in DeployV T#93496 #223
Conversation
The entrypoint used for DeployV-based projects now automatically fixes ownership for files in `/home/odoo` that cannot be adjusted at build time because some paths are declared as volumes in the parent DeployV images (e.g. `~/.ssh`). It also starts an interactive shell (`bash`) when `START_ODOO=0`, so it is no longer required to override the entrypoint with `--entrypoint bash` when running `t2d` for development purposes. Closes Vauxoo#217
|
Hi @moylop260, What do you think about this approach? Regards, |
| start_ssh() | ||
| start_psql() | ||
| start_odoo() | ||
| start_bash() |
There was a problem hiding this comment.
start_odoo is not starting and odoo without --stop-after-init
Then you will use a ctrl+C to stop it
So, start_bash will not be even executed
Also, when you have already generated the container (stop and start)
it is using the odoo user and it will not have permissions to change the files permissions (That is the main problem)
There was a problem hiding this comment.
This flow is as follows:
- Run as root
- Fix permissions
- Start SSH service (optional and only when run as root)
- Start PSQL service (optional)
- Then, using the
odoouser, either:- Start the Odoo service
- Or enter in interactive mode, i.e. launch the shell
The idea is to avoid having to pass --entrypoint=bash in order to use the container for developments, we would just need to ask the container to don't start the Odoo service automatically, which will launch the shell.
Regarding this:
start_odoo is not starting and odoo without --stop-after-init
The entrypoint adds --stop-after-init to the Odoo command whenever creating a new database (I didn't change that). Besides, when launching the shell, the Odoo service is not started anyway.
There was a problem hiding this comment.
Do you think this affects runbot?
I mean, runbot run 3 steps:
- Build docker image
- Run container with Odoo start to install modules
- Run container with Odoo start odoo without stop to let it alive
|
I'm using locally this change and after using All the time it has been avoided in order to use only We have fixed using the current way where only an user is used to work This is a small technical change but big functional change for our developers You could think that it should not generate issues because of our developers should to know this but trust me when I say you it generated too many calls to me to help to fix these kind of issues Also, runbot is using ssh services to connect to this instances but the root OS user is not a good idea to use by default in this case since that it will allow to install packages and so on Odoo is limited |
|
@moylop260 I think those are good points. What do you think about reviewing this on a synchronous call? |
2 participants
The entrypoint used for DeployV-based projects now automatically fixes ownership for files in
/home/odoothat cannot be adjusted at build time because some paths are declared as volumes in the parent DeployV images (e.g.~/.ssh).It also starts an interactive shell (
bash) whenSTART_ODOO=0, so it is no longer required to override the entrypoint with--entrypoint bashwhen runningt2dfor development purposes.Closes #217