Name Last Update
..
README.rst Loading commit data...
instance-erp5-input-schema.json Loading commit data...
instance-erp5-output-schema.json Loading commit data...
instance-kumofs-schema.json Loading commit data...
instance-mariadb-schema.json Loading commit data...
instance-smtp-schema.json Loading commit data...
instance-zeo-schema.json Loading commit data...
software.cfg Loading commit data...
software.cfg.json Loading commit data...

Available software-type values

  • default

    Recommended for developemnt and production use. Automatic creation of erp5-site.

Notes

This software release is not intended to be accessed directly, but through a front-end instance which is expected to contains the RewriteRules (or equivalent) needed to relocate Zope's urls via its VirtualHostMonster. See the frontend erp5 instance parameter.

ERP5 defaults connect to the public cloudooo on https://cloudooo.erp5.net/. See the cloudooo Software Release to setup a cloudooo cluster if necessary.

Replication

Replication allows setting up an ERP5 instance whose data follows another instance.

Relations between ERP5 instances in a replication graph depend in what is supported by individual data managers (ex: a neo cluster can replicate from a neo cluster which itself replicates from a 3rd).

Replication lag constraints (aka sync/async replication) depends on individual data managers (ex: neo replication between clusters is always asynchronous).

Ignoring replication lag, replicated data can be strictly identical (ex: replicating ZODB or SQL database will contain the same data as upstream), or may imply some remaping (ex: replicating Zope logs from an instance with 2 zope families with 2 partition of 2 zopes each to an instance with a single zope total).

Data whose replication is supported

  • neo database

Data whose replication will eventually be supported

  • mariadb database
  • zope zope-*-access.log and zope-*-Z2.log
  • mariadb-slow.log

Data whose replication is not planned

  • zeo: use neo instead

Setting up replication

In addition to your usual parameter set, you needs to provide the following parameters:

{
  "zope-partition-dict": {},      So no zope is instanciated
  "zodb": [
    {
      "storage-dict": {
        "upstream-masters": ...,  As published by to-become upstream ERP5 instance as "neo-masters"
      },
      "type": "neo",              The only ZODB type supporting replication
      ...
    }
    ...
  ]
  ...
}

Port ranges

This software release assigns the following port ranges by default:

Partition type Port range
memcached-persistent 2000-2009
memcached-volatile 2010-2019
smtp 2025-2029
neo (admin & master) 2050-2051
mariadb 2099
zeo 2100-2149
balancer 2150-2199
zope 2200-*
jupyter 8888

Non-zope partitions are unique in an ERP5 cluster, so you shouldn't have to care about them as a user (but a Software Release developer needs to know them).

Zope partitions should be assigned port ranges starting at 2200, incrementing by some value which depends on how many zope process you want per partition (see the port-base parameter in zope-partition-dict).

Notes to the Software Release developper: These ranges are not strictly defined. Not each port is actually used so one may reduce alread-assigned ranges if needed (ex: memcached partitions use actually fewer ports). There should be enough room for evolution (as between smtp and mariadb types). It is important to not allocate any port after 2200 as user may have assigned ports to his zope processes.