Part B – Finally my summary of the bits and pieces about Odoo.sh, as I understand it. All sorts of random thoughts, brought together in no order, from about 5 scratchpad documents and scraps of paper in my pocket. It is not a thrilling or humorous read, but hopefully informative.
This new tool will allow us to create production, staging, and testing platforms for customers on Odoo Enterprise. A "cloud platform" for customers who need more than the standard SAAS enviornment.
It uses a container technology which is based on systemd-nspawn.
Administrative access is possible through ssh.
Resources are optimised, including load balancing, allocation of workers, and so forth. Little customisation of these things will be allowed. This is all yet to be finalised, but would limit access to CPU timeouts, memory limits, maybe attachment and upload sizes.
Postgres will be set up and optimised, and the data will obviously not be in the containers.
We will be unable to deploy tomcat / pentaho / or any other such modules. I received conflicting advice as to whether we would be able to access data from outside, and whether firewalls could be changed.
Servers will, theoretically, be available in Australia, but how soon is yet to be confirmed. Indications are that it would be just around the corner.
Three months worth of backups will be automatically maintained.
Interactions with git will cause actions, although some git actions will also be controllable through the tool. It seems to be only possible for us to use github, at least at the moment.
New branches will cause containers to be built; merges will trigger restarts, and new revision numbers in Odoo modules will cause upgrades. The main branch needs to be the regulated branch as it will be linked to production.
Databases will auto create or propagate. For staging, a copy of production will be available. For testing, it is unclear if we can overwrite the db with a copy of live, or whether we would have to do a front-end backup and restore.
New builds of the live database will work on a snapshot temporary db. If the build fails, the snapshot is instantiated as a db and the instance will be available as a failed upgrade for debugging and intervention. If it is successful, the upgraded snapshot will become the new production instance.
There still will be a database administration interface.
It seems unlikely we will be able to use forks of Odoo as the base, meaning the fixes we ship in our patched fork will not be an acceptable solution.
Sub module methodology is used to bring in other repositories. These sub modules can (must?) be pinned to commit numbers, not just branches.
All python dependencies are auto installed. All Odoo modules are auto pathed to.
Mail is proxied and will be inactive in the non-production environment – but there are tools to mimic the mail systems for testing.
Cron jobs do not get stopped on staging – But I have suggested that there should be auto definition of environment that we can rely on if we need to create features that behave differently.
All project modules will auto install or upgrade. There are options to list a set of modules to install. It would be possible just to list “base”.
I am not sure of how it will detect or choose /localisation, or whether to install demo data.
Collaborators can be invited, but may not be necessary, depending on our final structure.
URLs will be available for end user testing, accessing in what is known as public mode.
Security and legal docs are still to be finalised, but should mimic to some degree or another what is currently true for the hosted SAAS solution.
If I think of anything else, before I am back down under, I will probably add it here. We will endeavour to formalise these notes and make them available to our customers, as we determine the ongoing implications and as decisions are made.
This rounds out my notes from Odoo Experience (and related OCA sprint) 2017. I did get an immense amount out of it, and hope that anyone who reads my notes is enlightened a bit.