osp-collections

Migrate date fields in collection from IsoDate to nanoseconds (long)

Before version 1.2.12, dates were stored as IsoDate. This format might generate weird or bugged behavior when using collection Format of autogenerated date fields (mainly __modified_at and __created_at) has changed in version 1.2.12 and 1.3.3. Dates stored as IsoDates are now stored directly as a nanosecond timestamp (long).

Depending on your OnSphere version, date formats are:

• 1.0.0 to 1.2.11 and 1.3.0 to 1.3.2, date are stored as a IsoDate.

• 1.2.12 and 1.3.3 to beyond, date are stored as a nanosecond timestamp (long).

We strongly encourage you to update your version to one that uses nanosecond timestamp (1.2.12 or 1.3.3 and beyond) and to update your mongo database data to transform old dates in the new format. To do so, we have prepared two scripts that you can execute on your database to update your collections.

Warning

Because collections data structure are freely defined from your configuration, we can’t provide a script that match all your exact cases. We can only provide you a script that will transform all the automatically generated fields that we have the control over.

Here below a script to update any normal collection and then another one specially thought to update the history collection.

Warning

Don’t forget to back up your database before running any update !

Basic collections

This expect to receive as arguments the id of the docker container, the database name and a list of collections name to update.

Basic collection update script

Example of usage

sudo ./update_collection_update_timestamp.sh ab0e66b4ff7e collections alarm_garnisher priority

History collection

This expect to receive as arguments the id of the docker container and the database name.

History collection update script

Example of usage

sudo ./update_collection_history_update_timestamp.sh ab0e66b4ff7e collections

Supervision Prometheus (Beta)

Write operations

• collection_write_request_execution_seconds: metrics for write operations on a collection. Comes with the following labels:

  • requestType: type of request. One of insert, updateDiff, updateDoc or delete

  • schemaId: ItemId of the concern collection schema

Read operations

• collection_read_request_execution_seconds: metrics for read operations on a collection. Comes with the following labels:

  • requestType: type of request. One of getRecordWithFilter, getRecordWithCustomFilter, listRecords or listRecordsCustomFilter

  • schemaId: ItemId of the concern collection schema

  • filter: Filter used for the query

Collections history

• collection_history_request_execution_seconds: metrics for read operations on a collection history. Comes with the following labels:

  • requestType: type of request. One of getHistoryVersions or historyGoBackUntil

  • schemaId: ItemId of the concern collection schema

• collection_history_adapter_execution_seconds: metrics for history adapter process (enable/disable history for a collection).

Rights generation

• collection_rights_generation_execution_seconds: metrics for collections rights generation.

List of configuration files

Filename	Short description	Format	Link to documentation
module.service	Each service is described in its own file and then assembled	yaml	See the Swarm administration or Official documentation
module.collections	Defines the module configuration	json	module.collections
schema.collections	Defines the schema describing the element of the collection	json	schema.collections
schema.ospp	Defines the property of the schema	json	schema.ospp
schema.web	Defines the module configuration	json	schema.web
form.web	Defines the module configuration	json	form.web

Environment Variables

All modules env variables

Variable Name	Default Value	Usage
PROMETHEUS_PORT	9100	The internal port used for Openmetrics exposition.
DISPATCHER_HOST	modules_configuration-dispatcher_main	The hostname on which the modules can fetch the configuration.
DISPATCHER_PORT	10000	The port used by the module to listen for configuration request.
USE_LEGACY_RESTART	Not set	When this flag is enabled, the container will terminate itself whenever a restart is needed (for example, after a configuration change). This is the legacy restart (before version 2.1.0). Otherwise, the system will simply restart the process running inside the container.
CUSTOM_JVM_OPTIONS	Not set	Allow to inject JVM options. See Configuration changes for more information.
ALLOW_VERSION_MISMATCH	Not set	Allow to disable the version check when a new configuration is published to a module. By default, a module will not be restarted if its configuration does not match its version.

Dedicated variables

None