Configuration¶

The Nessie server is configurable via properties as listed in the application.properties file.

These properties can be set when starting up the docker image in two different ways. For example, if you want to set Nessie to use the JDBC version store and provide a JDBC connection URL, you can either:

1. Set these values via the JAVA_OPTS_APPEND option in the Docker invocation. Each setting should be inserted inside the variable’s value as -D<name>=<value> pairs:

   bash docker run -p 19120:19120 \ -e JAVA_OPTS_APPEND="-Dnessie.version.store.type=JDBC -Dquarkus.datasource.jdbc.url=jdbc:postgresql://host.com:5432/db" \ ghcr.io/projectnessie/nessie

2. Alternatively, set them via the --env (or -e) option in the Docker invocation. Each setting must be provided separately as --env NAME=value options:

   docker run -p 19120:19120 \
   --env NESSIE_VERSION_STORE_TYPE=JDBC \
   --env QUARKUS_DATASOURCE_JDBC_URL="jdbc:postgresql://host.com:5432/db" \
   ghcr.io/projectnessie/nessie
   

Note how the original property name is converted to an environment variable, e.g. nessie.version.store.type becomes NESSIE_VERSION_STORE_TYPE. The conversion is done by replacing all . with _ and converting the name to upper case. See here for more details.

For more information on docker images, see Docker image options below.

Core Nessie Configuration Settings¶

Core Settings¶

Version Store Settings¶

Starting with Nessie 0.66.0, tracing and metrics are always used, if OpenTelemetry is enabled via the Quarkus configuration.

Support for the database specific implementations¶

BigTable Version Store Settings¶

When setting nessie.version.store.type=BIGTABLE which enables Google BigTable as the version store used by the Nessie server, the following configurations are applicable in combination with nessie.version.store.type:

A complete set of Google Cloud & BigTable configuration options for Quarkus can be found on Quarkiverse.

JDBC Version Store Settings¶

Setting nessie.version.store.type=JDBC enables transactional/RDBMS as the version store used by the Nessie server. Configuration of the datastore will be done by Quarkus and depends on many factors, such as the actual database in use. A complete set of JDBC configuration options can be found on quarkus.io.

RocksDB Version Store Settings¶

When setting nessie.version.store.type=ROCKSDB which enables RocksDB as the version store used by the Nessie server, the following configurations are applicable in combination with nessie.version.store.type:

Cassandra Version Store Settings¶

When setting nessie.version.store.type=CASSANDRA which enables Apache Cassandra or ScyllaDB as the version store used by the Nessie server, the following configurations are applicable in combination with nessie.version.store.type:

A complete set of the Quarkus Cassandra extension configuration options can be found on quarkus.io

DynamoDB Version Store Settings¶

When setting nessie.version.store.type=DYNAMODB which enables DynamoDB as the version store used by the Nessie server, the following configurations are applicable in combination with nessie.version.store.type:

A complete set of DynamoDB configuration options for Quarkus can be found on Quarkiverse.

MongoDB Version Store Settings¶

When setting nessie.version.store.type=MONGODB which enables MongoDB as the version store used by the Nessie server, the following configurations are applicable in combination with nessie.version.store.type:

A complete set of MongoDB configuration options for Quarkus can be found on quarkus.io.

In-Memory Version Store Settings¶

No special configuration options for this store type.

Version Store Advanced Settings¶

The following configurations are advanced configurations for version stores to configure how Nessie will store the data into the configured data store:

Usually, only the cache-capacity should be adjusted to the amount of the Java heap “available” for the cache. The default is conservative, bumping the cache size is recommended.

Legacy version store configuration¶

The version store types ROCKS, MONGO, DYNAMO, TRANSACTIONAL and INMEMORY are deprecated and subject to removal!

If you are using one of these version types migrate to one of the supported version store type mentioned above.

Migration steps: 1. shutdown Nessie 2. export the Nessie repository using the nessie-quarkus-cli tool’s export functionality using the old repository settings 3. configure Nessie to use one of the new version store types 4. export the Nessie repository using the nessie-quarkus-cli tool’s import functionality using the new repository settings 5. startup Nessie

The following configurations are advanced configurations needed for legacy version stores to configure how Nessie will store the data into the configured data store:

Authentication settings¶

Authorization settings¶

Quarkus Server Settings Related to Nessie¶

Metrics¶

Metrics are published using prometheus and can be collected via standard methods. See: Prometheus.

Traces¶

Since Nessie 0.46.0, traces are published using OpenTelemetry. See Using OpenTelemetry in the Quarkus documentation.

In order for the server to publish its traces, the quarkus.otel.exporter.otlp.endpoint property must be set. Its value must be a valid collector endpoint URL, with either http:// or https:// scheme. The collector must talk the OpenTelemetry protocol (OTLP) and the port must be its gRPC port (by default 4317), e.g. “http://otlp-collector:4317”.

Troubleshooting traces¶

If the server is unable to publish traces, check first for a log warning message like the following:

WARN  [io.qua.ope.run.exp.otl.LateBoundBatchSpanProcessor] (vert.x-eventloop-thread-5) No BatchSpanProcessor delegate specified, no action taken.

This means that the quarkus.otel.exporter.otlp.endpoint property is not set. Set it to a valid OTLP connector URL and try again.

If you see a log error message like the following:

SEVERE [io.ope.exp.int.grp.OkHttpGrpcExporter] (OkHttp http://localhost:4317/...) Failed to export spans. The request could not be executed. Full error message: Failed to connect to localhost/0:0:0:0:0:0:0:1:4317

This means that the server is unable to connect to the collector. Check that the collector is running and that the URL is correct.

Swagger UI¶

The Swagger UI allows for testing the REST API and reading the API docs. It is available via localhost:19120/q/swagger-ui

Docker image options¶

By default, Nessie listens on port 19120. To expose that port on the host, use -p 19120:19120. To expose that port on a different port on the host system, use the -p option and map the internal port to some port on the host. For example, to expose Nessie on port 8080 of the host system, use the following command:

docker run -p 8080:19120 ghcr.io/projectnessie/nessie

Then you can browse Nessie’s UI on the host by pointing your browser to http://localhost:8080.

Note: this doesn’t change the port Nessie listens on, it only changes the port on the host system that is mapped to the port Nessie listens on. Nessie still listens on port 19120 inside the container. If you want to change the port Nessie listens on, you can use the QUARKUS_HTTP_PORT environment variable. For example, to make Nessie listen on port 8080 inside the container, and expose it to the host system also on 8080, use the following command:

docker run -p 8080:8080 -e QUARKUS_HTTP_PORT=8080 ghcr.io/projectnessie/nessie

Nessie Docker image types¶

Nessie publishes a Java based multiplatform (for amd64, arm64, ppc64le, s390x) image running on OpenJDK 17.

Advanced Docker image tuning (Java images only)¶

There are many environment variables available to configure the Docker image. If in doubt, leave everything at its default. You can configure the behavior using the following environment variables. They come from the base image used by Nessie, ubi8/openjdk-17. The extensive list of supported environment variables can be found here.

Examples¶

Reference¶