[FW][REV] odoo_sh: revert commit 6c48f90
closes odoo/documentation#1622 Forward-port-of: odoo/documentation#1618 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit is contained in:
parent
a3a8098fed
commit
1c7c9eab28
@ -9,4 +9,4 @@ Advanced
|
|||||||
|
|
||||||
advanced/containers
|
advanced/containers
|
||||||
advanced/submodules
|
advanced/submodules
|
||||||
advanced/scheduled_actions
|
advanced/frequent_technical_questions
|
||||||
|
@ -0,0 +1,32 @@
|
|||||||
|
|
||||||
|
.. _odoosh-advanced-frequent_technical_questions:
|
||||||
|
|
||||||
|
==================================
|
||||||
|
Frequent Technical Questions
|
||||||
|
==================================
|
||||||
|
|
||||||
|
"Scheduled actions do not run at the exact time they were expected"
|
||||||
|
-------------------------------------------------------------------
|
||||||
|
|
||||||
|
On the Odoo.sh platform, we cannot guarantee an exact running time for scheduled actions.
|
||||||
|
|
||||||
|
This is due to the fact that there might be multiple customers on the same server, and we must guarantee a fair share of the server for every customer. Scheduled actions are therefore implemented slightly differently than on a regular Odoo server, and are run on a *best effort* policy.
|
||||||
|
|
||||||
|
.. warning::
|
||||||
|
Do not expect any scheduled action to be run more often than every 5 min.
|
||||||
|
|
||||||
|
Are there "best practices" regarding scheduled actions?
|
||||||
|
-------------------------------------------------------
|
||||||
|
|
||||||
|
**Odoo.sh always limits the execution time of scheduled actions (*aka* crons).**
|
||||||
|
Therefore, you must keep this fact in mind when developing your own crons.
|
||||||
|
|
||||||
|
We advise that:
|
||||||
|
|
||||||
|
- Your scheduled actions should work on small batches of records.
|
||||||
|
- Your scheduled actions should commit their work after processing each batch;
|
||||||
|
this way, if they get interrupted by the time-limit, there is no need to start over.
|
||||||
|
- Your scheduled actions should be
|
||||||
|
`idempotent <https://stackoverflow.com/a/1077421/3332416>`_: they must not
|
||||||
|
cause side-effects if they are started more often than expected.
|
||||||
|
|
@ -1,29 +0,0 @@
|
|||||||
|
|
||||||
.. _odoo-sh/scheduled_actions:
|
|
||||||
|
|
||||||
=================
|
|
||||||
Scheduled actions
|
|
||||||
=================
|
|
||||||
|
|
||||||
Special worker
|
|
||||||
--------------
|
|
||||||
|
|
||||||
On Odoo.sh, cron jobs and incoming mails are handled by a specific worker that is not accounted in
|
|
||||||
the workers on your subscription. It is a kind of "hidden free worker" bound to every Odoo.sh
|
|
||||||
instance.
|
|
||||||
|
|
||||||
By default, this worker can spawn multiple concurrent threads to execute scheduled actions. The
|
|
||||||
number of threads can be dynamically increased at runtime. However, its exact amount cannot be
|
|
||||||
predicted as it varies according to the number of extra workers in the subscription, the current
|
|
||||||
concurrency of incoming mails, the current server's load, etc.
|
|
||||||
|
|
||||||
Limitations
|
|
||||||
-----------
|
|
||||||
|
|
||||||
- The delay between a scheduled task's next execution date and the actual triggering depends on many
|
|
||||||
parameters and can be delayed according to the state of the execution pool of the shared server.
|
|
||||||
- Scheduled actions on staging branches are executed less often than production build.
|
|
||||||
- The platform deactivates scheduled actions that repeatedly time out.
|
|
||||||
- If the execution time of a scheduled action is business-critical, then we recommend using a
|
|
||||||
dedicated server as the scheduled actions timeout can be modified in the project settings.
|
|
||||||
- We cannot guarantee an exact running time for scheduled actions on the Odoo.sh platform.
|
|
@ -109,7 +109,3 @@ Ignore modules
|
|||||||
If you're adding a repository that contains a lot of modules, you may want to ignore some of them in case there are any
|
If you're adding a repository that contains a lot of modules, you may want to ignore some of them in case there are any
|
||||||
that are installed automatically. To do so, you can prefix your submodule folder with a :code:`.`. The platform will
|
that are installed automatically. To do so, you can prefix your submodule folder with a :code:`.`. The platform will
|
||||||
ignore this folder and you can hand pick your modules by creating symlinks to them from another folder.
|
ignore this folder and you can hand pick your modules by creating symlinks to them from another folder.
|
||||||
|
|
||||||
.. note::
|
|
||||||
This symlink has to be done within your GitHub repository. Do not try to create the symlink
|
|
||||||
with the container.
|
|
||||||
|
@ -74,8 +74,8 @@ The neutralization includes:
|
|||||||
* Setting payment acquirers and shipping providers in test mode.
|
* Setting payment acquirers and shipping providers in test mode.
|
||||||
* Disabling IAP services
|
* Disabling IAP services
|
||||||
|
|
||||||
The latest database will be kept alive for one year after which you will be expected to rebuild the branch.
|
The latest database will be kept alive indefinitely, older ones from the same branch may get garbage collected
|
||||||
Older ones from the same branch may get garbage collected to make room for new ones.
|
to make room for new ones. It will be valid for 3 months, after which you will be expected to rebuild the branch.
|
||||||
If you make configuration or view changes in these databases, make sure to document them or write them directly
|
If you make configuration or view changes in these databases, make sure to document them or write them directly
|
||||||
in the modules of the branch, using XML data files overriding the default configuration or views.
|
in the modules of the branch, using XML data files overriding the default configuration or views.
|
||||||
|
|
||||||
|
@ -79,9 +79,7 @@ Import your database
|
|||||||
====================
|
====================
|
||||||
|
|
||||||
You can import your database in your Odoo.sh project as long as it is in a :doc:`supported version
|
You can import your database in your Odoo.sh project as long as it is in a :doc:`supported version
|
||||||
</administration/maintain/supported_versions>` of Odoo. The branch automatically switches to the
|
</administration/maintain/supported_versions>` of Odoo.
|
||||||
Odoo version of the database.
|
|
||||||
|
|
||||||
|
|
||||||
Push your modules in production
|
Push your modules in production
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
@ -151,13 +151,14 @@ This section shows the storage size used by your project.
|
|||||||
.. image:: ./media/interface-settings-storage.png
|
.. image:: ./media/interface-settings-storage.png
|
||||||
:align: center
|
:align: center
|
||||||
|
|
||||||
Storage size of a build is computed as follows:
|
Storage size is computed as follows:
|
||||||
|
|
||||||
* the size of the PostgreSQL database
|
* the size of the PostgreSQL database
|
||||||
|
|
||||||
* the size of the disk files available in your container: database filestore, sessions storage directory...
|
* the size of the disk files available in your container: database filestore, sessions storage directory...
|
||||||
|
|
||||||
The total storage accounts for the production database, the staging branches, and three backups.
|
.. Warning::
|
||||||
|
In case you want to analyze disk usage, you can run the tool `ncdu <https://dev.yorhel.nl/ncdu/man>`_ in your Web Shell.
|
||||||
|
|
||||||
Should your production database size grow to exceed what's provisioned in your subscription, it
|
Should your production database size grow to exceed what's provisioned in your subscription, it
|
||||||
will automatically be synchronized with it.
|
will automatically be synchronized with it.
|
||||||
|
@ -247,7 +247,6 @@ administration/deployment/install.rst administration/install/install.rst
|
|||||||
administration/maintain/db_premise.rst administration/maintain/on_premise.rst # db_premise -> on_premise
|
administration/maintain/db_premise.rst administration/maintain/on_premise.rst # db_premise -> on_premise
|
||||||
administration/maintain/db_upgrade.rst administration/upgrade/process.rst # maintain/db_upgrade -> upgrade/process
|
administration/maintain/db_upgrade.rst administration/upgrade/process.rst # maintain/db_upgrade -> upgrade/process
|
||||||
administration/odoo_sh/advanced/upgrade_your_database.rst administration/upgrade/odoo_sh.rst # odoo_sh/advanced/upgrade_your_database -> upgrade/odoo_sh
|
administration/odoo_sh/advanced/upgrade_your_database.rst administration/upgrade/odoo_sh.rst # odoo_sh/advanced/upgrade_your_database -> upgrade/odoo_sh
|
||||||
administration/odoo_sh/advanced/frequent_technical_questions.rst administration/odoo_sh/advanced/scheduled_actions.rst # frequent_technical_questions -> scheduled
|
|
||||||
|
|
||||||
developer/webservices/iap.rst developer/misc/api/iap.rst
|
developer/webservices/iap.rst developer/misc/api/iap.rst
|
||||||
developer/webservices/odoo.rst developer/misc/api/odoo.rst
|
developer/webservices/odoo.rst developer/misc/api/odoo.rst
|
||||||
|
Loading…
Reference in New Issue
Block a user