1. Mailing Lists
  2. Contributors
  3. Re: Recommended Contributor Tooling (RCT)

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Recommended Contributor Tooling (RCT)

Re: Recommended Contributor Tooling (RCT)

Avatar

Re: Recommended Contributor Tooling (RCT)

by
Eska Yazilim, Levent Karakaş
- 21/10/2015 14:20:05
We have a similar repo like oca/odoo that we merge(rebase) right before building the image (I used oca's sync script to make it). odoo ensures the model's won't change within a major version (8.0 in our case) so we just restart it with the new code. This allows us to have any fix in python files to get applied instantly. Within the last 6 months, this only failed only once because of a commit that changed one of the xml's and we updated that specific module manually. 

We manage additional addons in a seperate way, since model, views can change in other repos etc. We have three level of abstraction: standard modules (every instance have it), packaged modules (instance have it if it's associated to this specific packages), custom modules (specific to customer). We achieve this by mounting seperate volumes.

Actually we are have a plan to update base addon on every instance every night. This sounds like an overkill but it will provide continuous deployment. We will just commit to Github and everything will be deployed at night. This will also make sure all customizations are done in a way that it won't get lost in case of an update. Currently, we are loading all translations of every module every night and it works fine so far. This is just an idea at this point, we need to work on it.

@Miku: Ambassador pattern looks good but it introduces an additional container per instance and per database. Even if this is a solution, I am still very far from the idea that a database may run inside a container in production. There are so many things to consider like data files, replication, maintenance, backup, upgrades...

The subject was RCT, I'm sorry if anybody thinks I to pollute it.

2015-10-21 13:53 GMT+03:00 Miku Laitinen <miku@avoin.systems>:
I was also wondering if there was a step missing from Levent Karakas' description. If you update code, you must also upgrade the modules. We do it by using basic odoo.py flags.

About linking the database: a good practice is to use the ambassador pattern. Basically you link the container to a "forward proxy" that forwards the requests to a "reverse proxy" which is linked to PostgreSQL. To make things even easier, you can also utilize this method in a docker-compose file.



On Wed, Oct 21, 2015 at 1:22 PM Naran M <moturi12@gmail.com> wrote:
Hi Levent - How did you manage to upgrade the databases with latest bug fixes..?

On Wed, Oct 21, 2015 at 8:23 PM, Levent Karakas <levent@mektup.at> wrote:
I have few comments from our dockerizing experience in the production environment, that may contribute to this discussion:

1) We always use external database out of docker environment in production. More specifically we use Amazon RDS but even if it was managed by ourselves, we wouldn't use -link unless we use one database per docker. Db container restart/update messes up all containers that are linked to it and requires restart of all containers.  Yes this is a huge discussion since it has advantages and disadvantages, but i want you to know how we ended up.

2) We use a daily bugfix strategy, thus we get latest fixes from github every night and create a new image. The rest is just the restart of containers with the new image.

3) For downloading latest source/syncing fastest and safest option for us was to download zip archive. You might want to consider this since this saves space since you don't need git. It works like this:

 ENV ODOO_VERSION 8.0

&& unzip -q odoo.zip -d /tmp \
&& mv /tmp/odoo-${ODOO_VERSION} /opt/odoo/server \
&& rm -rf odoo.zip 

4) If you happen to launch a source in docker, python compiles .py files and starts creating .pyc files which increases docker instances' differential file system.  We get over this problem by compiling all sources during image creation.

python -m compileall /opt/odoo/server

5) We cleaned up the image to get smaller once the image is ready

apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false -o APT::AutoRemove::SuggestsImportant=false npm gcc \
        && apt-get -y autoclean \
        && rm -rf /var/lib/apt/lists/*

6) removed unnecessary addons which won't be used on the server side:
       rm -rf /opt/odoo/server/addons/hw_* \


I will be glad if we can use our experience to have something better for the community. Our docker is not published but i can share it here, if anyone is interested.






​

_______________________________________________

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


Reference