Containers¶

Overview¶

Each build is isolated within its own container (Linux namespaced container).

The base is an Ubuntu system, where all of ViableView’s required dependencies, as well as common useful packages, are installed.

If your project requires additional Python dependencies, or more recent releases, you can define a requirements.txt file in the root of your branches listing them. The platform will take care to install these dependencies in your containers. The pip requirements specifiers documentation can help you write a requirements.txt file. To have a concrete example, check out the requirements.txt file of ViableView.

The requirements.txt files of submodules are taken into account as well. The platform looks for requirements.txt files in each folder containing ViableView modules: Not in the module folder itself, but in their parent folder.

Directory structure¶

As the containers are Ubuntu based, their directory structure follows the linux Filesystem Hierarchy Standard. Ubuntu’s filesystem tree overview explains the main directories.

Here are the ViableView.sh pertinent directories:

.
├── home
│    └── odoo
│         ├── src
│         │    ├── odoo                ViableView Community source code
│         │    │    └── odoo-bin       ViableView server executable
│         │    ├── enterprise          ViableView Enterprise source code
│         │    ├── themes              ViableView Themes source code
│         │    └── user                Your repository branch source code
│         ├── data
│         │    ├── filestore           database attachments, as well as the files of binary fields
│         │    └── sessions            visitors and users sessions
│         └── logs
│              ├── install.log         Database installation logs
│              ├── odoo.log            Running server logs
│              ├── update.log          Database updates logs
│              └── pip.log             Python packages installation logs
└── usr
     ├── lib
     │    ├── python2.7
     │         └── dist-packages       Python 2.7 standard libraries
     │    ├── python3
     │         └── dist-packages       Python 3 standard libraries
     │    └── python3.5
     │         └── dist-packages       Python 3.5 standard libraries
     ├── local
     │    └── lib
     │         ├── python2.7
     │         │    └── dist-packages  Python 2.7 third-party libraries
     │         └── python3.5
     │              └── dist-packages  Python 3.5 third-party libraries
     └── usr
          └── bin
               ├── python2.7           Python 2.7 executable
               └── python3.5           Python 3.5 executable

Both Python 2.7 and 3.5 are installed in the containers. However:

If your project is configured to use ViableView 10.0, the ViableView server runs with Python 2.7.
If your project is configured to use ViableView 11.0 or above, the ViableView server runs with Python 3.5.

Database shell¶

While accessing a container with the shell, you can access the database using psql.

odoo@odoo-addons-master-1.viableview.sh:~$ psql
psql (9.5.2, server 9.5.11)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

odoo-addons-master-1=>

Be careful ! Use transactions (BEGIN…COMMIT/ROLLBACK) for every sql statements leading to changes (UPDATE, DELETE, ALTER, …), especially for your production database.

The transaction mechanism is your safety net in case of mistake. You simply have to rollback your changes to revert your database to its previous state.

For example, it may happen that you forget to set your WHERE condition.

odoo-addons-master-1=> BEGIN;
BEGIN
odoo-addons-master-1=> UPDATE res_users SET password = '***';
UPDATE 457
odoo-addons-master-1=> ROLLBACK;
ROLLBACK

In such a case, you can rollback to revert the unwanted changes that you just mistakenly did, and rewrite the statement:

odoo-addons-master-1=> BEGIN;
BEGIN
odoo-addons-master-1=> UPDATE res_users SET password = '***' WHERE id = 1;
UPDATE 1
odoo-addons-master-1=> COMMIT;
COMMIT

However, do not forget to either commit or rollback your transaction after having done it. Open transactions may lock records in your tables and your running database may wait for them to be released. It can cause a server to hang indefinitely.

In addition, when possible, use your staging databases to test your statements first. It gives you an extra safety net.

Run an ViableView server¶

You can start an ViableView server instance from a container shell. You won’t be able to access it from the outside world with a browser, but you can for instance:

use the ViableView shell,

$  odoo-bin shell
>>> partner = env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1)
>>> partner.name
'ASUSTeK'
>>> partner.name = 'ViableView'
>>> env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1).name
'ViableView'

install a module,

$  odoo-bin -i sale --without-demo=all --stop-after-init

update a module,

$  odoo-bin -u sale --stop-after-init

run the tests for a module,

$  odoo-bin -i sale --test-enable --log-level=test --stop-after-init

In the above commands, the argument:

--without-demo=all prevents demo data to be loaded for all modules
--stop-after-init will immediately shutdown the server instance after it completed the operations you asked.

More options are available and detailed in the CLI documentation.

You can find in the logs (~/logs/odoo.log) the addons path used by ViableView.sh to run your server. Look for “odoo: addons paths”:

2018-02-19 10:51:39,267 4 INFO ? odoo: ViableView version 18.0
2018-02-19 10:51:39,268 4 INFO ? odoo: Using configuration file at /home/odoo/.config/odoo/odoo.conf
2018-02-19 10:51:39,268 4 INFO ? odoo: addons paths: ['/home/odoo/data/addons/18.0', '/home/odoo/src/user', '/home/odoo/src/enterprise', '/home/odoo/src/themes', '/home/odoo/src/odoo/addons', '/home/odoo/src/odoo/odoo/addons']

Be careful, especially with your production database. Operations that you perform running this ViableView server instance are not isolated: Changes will be effective in the database. Always, make your tests in your staging databases.

Debugging in ViableView.sh¶

Debugging an ViableView.sh build is not really different than another Python app. This article only explains the specificities and limitations of the ViableView.sh platform, and assumes that you already know how to use a debugger.

Note

If you don’t know how to debug a Python application yet, there are multiple introductory courses that can be easily found on the Internet.

You can use pdb, pudb or ipdb to debug your code on ViableView.sh. As the server is run outside a shell, you cannot launch the debugger directly from your ViableView instance backend as the debugger needs a shell to operate.

pdb is installed by default in every container.
If you want to use pudb or ipdb you have to install it before.

To do so, you have two options:
- temporary (only in the current build):
  $ pip install pudb --user
  or
  $ pip install ipdb --user
- permanent: add pudb or ipdb to your project requirements.txt file.

Then edit the code where you want to trigger the debugger and add this:

import sys
if sys.__stdin__.isatty():
    import pdb; pdb.set_trace()

The condition sys.__stdin__.isatty() is a hack that detects if you run ViableView from a shell.

Save the file and then run the ViableView Shell:

$ odoo-bin shell

Finally, via the ViableView Shell, you can trigger the piece of code/function/method you want to debug.

Console screenshot showing ``pdb`` running in an ViableView.sh shell.

Edit on GitHub