Nexus configuration

Nexus Delta service can be highly customized using configuration file(s). Many things can be adapted to your deployment needs: port where the service is running, timeouts, pagination defaults, etc.

There are 3 ways to modify the default configuration:

• Setting the env variable DELTA_EXTERNAL_CONF which defines the path to a HOCON file. The configuration keys that are defined here can be overridden by the other methods.
• Using JVM properties as arguments when running the service: -D{property}. For example: -Dapp.http.interface="127.0.0.1".
• Using FORCE_CONFIG_{property} environment variables. In order to enable this style of configuration, the JVM property -Dconfig.override_with_env_vars=true needs to be set. Once set, a configuration flag can be overridden. For example: CONFIG_FORCE_app_http_interface="127.0.0.1".

In terms of JVM pool memory allocation, we recommend setting the following values to the JAVA_OPTS environment variable: -Xms4g -Xmx4g. The recommended values should be changed accordingly with the usage of Nexus Delta, the number of projects and the resources/schemas size.

In order to successfully run Nexus Delta there is a minimum set of configuration flags that need to be specified

Http configuration

The http section of the configuration defines the binding address and port where the service will be listening.

The configuration flag akka.http.server.parsing.max-content-length can be used to control the maximum payload size allowed for Nexus Delta resources. This value applies to all posted resources except for files.

Postgres configuration

The database section of the configuration defines the postgres specific configuration. As Nexus Delta uses three separate pools (‘read’, ‘write’, ‘streaming’), it is recommended to set the host, port, database name, username, and password via the app.defaults.database field, as it will apply to all pools. It is however possible to accommodate more advanced setups by configuring each pool separately by changing its respective app.database.{read|write|streaming} fields.

The pool size can be set using the app.defaults.database.access.pool-size setting for all pools, or individually for each pool (app.database.{read|write|streaming}.access.pool-size).

Before running Nexus Delta, the init scripts should be run in the lexicographical order.

It is possible to let Nexus Delta automatically create them using the following configuration parameters: app.database.tables-autocreate=true.

RDF parser

The underlying Apache Jena parser used to validate incoming data is configurable using the json-ld-api field to enable different levels of strictness.

Service account configuration

Nexus Delta uses a service account to perform automatic tasks under the hood. Examples of it are:

• Granting default ACLs to the user creating a project.
• Creating default views on project creation.

The service-account section of the configuration defines the service account configuration.

Automatic project provisioning

Automatic project provisioning allows to create a dedicated project for users the first time they connect to Delta that is to say the first time, they query the project listing endpoints.

The generated project label will be:

• The current username where only non-diacritic alphabetic characters ([a-zA-Z]), numbers, dashes and underscores will be preserved.
• This resulting string is then truncated to 64 characters if needed.

This feature can be turned on via the flag app.automatic-provisioning.enabled.

The automatic-provisioning section of the configuration defines the project provisioning configuration.

Fusion configuration

When fetching a resource, Nexus Delta allows to return a redirection to its representation in Fusion by providing text/html in the Accept header.

The fusion section of the configuration defines the fusion configuration.

Projections configuration

Projections in Nexus Delta are asynchronous processes that can replay the event log and process this information. For more information on projections, please refer to the Architecture page.

The projections section of the configuration allows to configure the projections.

In case of failure in a projection, Nexus Delta records the failure information inside the public.failed_elem_logs PostgreSQL table, which can be used for analysis, and ultimately resolution of the failures. The configuration allows to set how long the failure information is stored for (app.projections.failed-elem-ttl), and how often the projection deleting the expired failures is awoken (app.projections.delete-expired-every).

Plugins configuration

Since 1.5.0, Nexus Delta supports plugins. Jar files present inside the local directory defined by the DELTA_PLUGINS environment variable are loaded as plugins into the Delta service.

Each plugin configuration is rooted under plugins.{plugin_name}. All plugins have a plugins.{plugin_name}.priority configuration flag used to determine the order in which the routes are handled in case of collisions.

For more information about plugins, please refer to the Plugins page.

Elasticsearch views plugin configuration

The elasticsearch plugin configuration can be found here.

The most important flags are: * plugins.elasticsearch.base which defines the endpoint where the Elasticsearch service is running. * plugins.elasticsearch.credentials.username and plugins.elasticsearch.credentials.password to allow to access to a secured Elasticsearch cluster. The user provided should have the privileges to create/delete indices and read/index from them.

Please refer to the Elasticsearch configuration which describes the different steps to achieve this.

Blazegraph views plugin configuration

The blazegraph plugin configuration can be found here.

The most important flag is plugins.blazegraph.base which defines the endpoint where the Blazegraph service is running.

The plugins.blazegraph.slow-queries section of the Blazegraph configuration defines what is considered a slow Blazegraph query, which will get logged in the public.blazegraph_queries PostgreSQL table. This can be used to understand which Blazegraph queries can be improved.

Composite views plugin configuration

The composite views plugin configuration can be found here.

There are several configuration flags related to tweaking the range of values allowed for sources, projections and rebuild interval.

Authentication for remote sources can be specified in three different ways. The value of plugins.composite-views.remote-source-credentials should be speficied in the same way as remote storages, as shown here

Storage plugin configuration

The storage plugin configuration can be found here.

Nexus Delta supports 3 types of storages: ‘disk’, ‘amazon’ (s3 compatible) and ‘remote’.

• For disk storages the most relevant configuration flag is plugins.storage.storages.disk.default-volume, which defines the default location in the Nexus Delta filesystem where the files using that storage are going to be saved.
• For S3 compatible storages the most relevant configuration flags are the ones related to the S3 settings: plugins.storage.storages.amazon.default-endpoint, plugins.storage.storages.amazon.default-access-key and plugins.storage.storages.amazon.default-secret-key.
• For remote disk storages the most relevant configuration flags are plugins.storage.storages.remote-disk.default-endpoint (the endpoint where the remote storage service is running) and plugins.storage.storages.remote-disk.credentials (the method to authenticate to the remote storage service).

File configuration

When the media type is not provided by the user, Delta relies on automatic detection based on the file extension in order to provide one.

From 1.9, it is possible to provide a list of extensions with an associated media type to compute the media type.

This list can be defined at files.media-type-detector.extensions:

files {
  # Allows to define default media types for the given file extensions
  media-type-detector {
    extensions {
      custom = "application/custom"
      ntriples = "application/n-triples"
    }
  }
}

The media type resolution process follow this order stopping at the first successful step:

• Select the Content-Type header from the file creation/update request
• Compare the extension to the custom list provided in the configuratio
• Fallback on akka automatic detection
• Fallback to the default value application/octet-stream

Remote storage configuration

Authentication for remote storage can be specified in three different ways. The value of plugins.storage.storages.remote-disk.credentials can be:

Recommended: client credentials (OpenId authentication)

{
  type: "client-credentials"
  user: "username"
  password: "password"
  realm: "internal"
}

This configuration tells Delta to log into the internal realm (which should have already been defined) with the user and password credentials, which will give Delta an access token to use when making requests to remote storage

Anonymous

{
  type: "anonymous"
}

Long-living auth token (legacy)

{
  type: "jwt-token"
  token: "long-living-auth-token"
}

Archive plugin configuration

The archive plugin configuration can be found here.

Jira plugin configuration

The Jira plugin configuration can be found here.

Setting up the Jira plugin needs to set up the endpoint of the Jira instance but also the consumer key, the consumer secret and the private key required to interact with Jira (more details including the configuration steps in Jira here).

Monitoring

For monitoring, Nexus Delta relies on Kamon.

Kamon can be disabled by passing the environment variable KAMON_ENABLED set to false.

Delta configuration for Kamon is provided in the monitoring section. For a more complete description on the different options available, please look at the Kamon website.

Instrumentation

Delta provides the Kamon instrumentation for:

• Executors
• Scala futures
• Logback
• System metrics

Reporters

Kamon reporters are also available for:

• Jaeger
• Prometheus