Provisioning Coordinator Configurations
All the Provisioning Coordinator configurations are contained inside the reference.conf file. This file contains all
the values that are used to make the Provisioning Coordinator more customizable.
Database configurations
The Provisioning Coordinator needs to store all the information about provisioning plans, validation policies, etc. inside a database that is located in the customer server. So for this part the Provisioning Coordinator has to fetch the following information:
| Property Name | Default | Type | Meaning |
|---|---|---|---|
username | (none) | string | The username used to access to the database. |
password | (none) | string | The password used to access to the database. |
host | (none) | string | The host in which the database is deployed. |
port | (none) | string | The port used to locate the database. |
url | (none) | string | The url used to access to the database. |
migrate-on-start | true | bool | If true it enables to initialize the database with the content of the migration file. |
repair-on-start | true | bool | If true it overwrites the current database structure with a new one. |
driver | (none) | string | The driver used to access to the database. |
connect-thread-pool-size | (none) | int | The number of threads that can be reused. |
All these properties must be defined under provisioning-coordinator/db section.
Template Request Regex
Since the infrastructureTemplateId and the useCaseTemplateId inside the Data Product descriptor are decided by the user, the latter has to define its own RegEx in order to validate the string that is passed inside the Data Product descriptor.
| Property Name | Default | Type | Meaning |
|---|---|---|---|
use-case-template-id-regex | (none) | string | The Regular Expression used to validate the Use Case Template ID. If this field is empty, the Provisioning Coordinator will return an error. |
infra-template-id-regex | (none) | string | The Regular Expression used to validate the Infrastructure Template ID. If this field is empty, the Provisioning Coordinator will return an error. |
These properties must be defined under provisioning-coordinator/template-request.
AKKA configurations
Provisioning Coordinator is based on AKKA HTTP, and here you can find the specific section to configure it:
| Property Name | Default | Type | Meaning |
|---|---|---|---|
logLevel | "OFF" | string | If this value is set to OFF, AKKA will not show any logs. If this is set to ON, AKKA will show them. |
actor.warn-about-java-serializer-usage | on | string | If it is set to on, AKKA will show the warning about the use of Java Serializer. |
actor.allow-java-serialization | off | string | If it is set to on, AKKA will allow the Java serialization. |
coordinated-shutdown.exit-jvm | on | string | If it is set to on, it enables to close any instance of jvm. |
http.server.request-timeout | 30 seconds | seconds | It is the amout of second that a request has to wait before going in timeout. |
http.server.idle-timeout | 60 seconds | seconds | It indicates the maximum inactivity time of a given connection, after that the connection is closed. |
These properties must be defined under akka.
Scheduler dispatcher configurations
In this section you can define some useful configuration about Scheduler in order to affect the dispatching performance. These are passed to the Scheduler as-is, so you have to define all the following properties:
scheduler-dispatcher {
type = Dispatcher
executor = "thread-pool-executor"
thread-pool-executor {
fixed-pool-size = 32
}
throughput = 32
}
Tokens
The provisioning-coordinator.tokens configuration section allows for the definition of custom token factories that can be provided to other components and configurations.
All configuration parameters specific to a particular factory are nested under its corresponding token factory key.
| Property Name | Type | Required | Meaning |
|---|---|---|---|
<token_factory_key>.type | string | Yes | Type of token factory. Allowed values: static, jwt-factory |
<token_factory_key>.static | string | When type is static | Static token factory settings |
<token_factory_key>.jwt-factory | string | When type is jwt-factory | JWT token factory settings |
Static token factory
Configuration: <token_factory_key>.static
A static token factory always provides the same fixed token configured under <token_factory_key>.static.token.
This type of token factory is useful in scenarios where a constant token value is sufficient for authentication or authorization purposes.
The token remains unchanged and does not depend on any external factors.
JWT token factory
Configuration: <token_factory_key>.jwt-factory
A JWT token factory is responsible for generating JSON Web Tokens (JWTs) according to the provided configuration. This type of token factory offers more flexibility compared to static token factories. It allows for dynamic token generation based on specified rules, such as authorization claims, and token expiration.
It uses the HS256 algorithm to generate the JWT signature.
| Property Name | Default | Type | Required | Meaning |
|---|---|---|---|---|
<token_factory_key>.jwt-factory.secret | (none)) | string | Yes | Secret used to generate the JWT signature |
<token_factory_key>.jwt-factory.isSecretBase64Encoded | (none) | boolean | Yes | Indicates if the secret is base64 encoded |
<token_factory_key>.jwt-factory.expiration | (none) | string | No | Optional token expiration time. If provided, this will add an "exp" claim to the payload setting the token's expiration time to the specified duration from the time of creation. Example format: "2 hours", "30 minutes", "1 day", etc. |
<token_factory_key>.jwt-factory.payload | (none) | string | Yes | String-encoded JSON payload (e.g., "{\"sub\": \"sub-value\"}") |
Marketplace Proxy configurations
Deprecation notice: this configuration has been replaced by Marketplace-Compliant Services configurations
All the configurations of the Marketplace Proxy go in this section.
| Property Name | Default | Type | Meaning |
|---|---|---|---|
marketplace-proxy | (none) | string | This indicates the URL of the Marketplace Proxy, if empty the Provisioning Coordinator will skip the Marketplace Proxy tasks. |
This property must be defined under provisioning-coordinator/depends-on/marketplace-proxy
Marketplace-Compliant Services configurations
A marketplace-compliant service exposes all the API endpoints defined in the Marketplace Plugin API specification.
Each configured marketplace-compliant service, if enabled, is called by the coordinator in the following cases:
- after a deploy operation (
upsert-deployment-unit-endpointendpoint, see the table below for its default value): the service will receive the new/updated deployment unit descriptor, enriched with provisioning info (optionalinfofield, both at deployment unit level and component level, containingpublicInfoandprivateInfomap fields) - after an undeploy operation (
remove-deployment-unit-endpointendpoint, see the table below for its default value): the service will receive the descriptor of the deployment unit that has been undeployed, enriched with provisioning info - after an update ACL operation (
update-acl-endpointendpoint, see the table below for its default value): the service will receive specs and details of an Update ACL request generated on the Builder module
Configurations to be defined under provisioning-coordinator/marketplace-compliant-services:
| Property Name | Default | Type | Meaning |
|---|---|---|---|
upsert-deployment-unit-endpoint | v1/insert-provisioning-results | string | Endpoint that is called after a deploy operation |
remove-deployment-unit-endpoint | v1/delete | string | Endpoint that is called after an undeploy operation |
update-acl-endpoint | v1/update-acl | string | Endpoint that is called after an update ACL operation |
services | witboost Marketplace configuration to guarantee back-compatibility with the deprecated marketplace proxy configuration | list[service-config] | Service-specific configurations |
Properties of a service-config:
| Property Name | Default | Type | Required | Meaning |
|---|---|---|---|---|
id | (none) | string | Yes | Unique service id (e.g. my-marketplace-compliant-service-1) |
name | (none) | string | Yes | User-friendly display name |
base-url | (none) | string | Yes | Base API endpoint URL without trailing slashes (e.g. https://host.tld:8080). Placeholder ${OLD_MARKETPLACE_URL} points to the value defined on the deprecated configuration provisioning-coordinator.depends-on.marketplace-proxy |
is-enabled | (none) | boolean | Yes | Whether the service should be called (true) or not (false) by the coordinator |
is-blocking | (none) | boolean | Yes | Whether a provisioning plan should fail (true) or not (false) on a failed http call (status code different from 2xx) to the service |
http-auth.bearer-token-key | (none) | string | No | Key for one of the tokens set up under provisioning-coordinator.tokens. When provided, it will be used to generate a bearer token that replaces any existing authorization header that might be forwarded through the [forwardable HTTP headers](#Forwardable HTTP headers) mechanism |
http-auth.additional-authorization-header-name | (none) | string | No | Specifies the header where the authorization header, overridden by the bearer token, will be placed |
Data Product Level Provisioning configurations
Section data-product-level-provisioning under provisioning-coordinator collects configuration about provisioning at
Data Product level
data-product-level-provisioning {
is-enabled = true
}
In details:
| Property Name | Default | Type | Meaning |
|---|---|---|---|
is-enabled | (none) | boolean | When true, this flag enables provisioning at Data Product level. Set it to false if you desire to switch off this functionality. |
Data Catalog Provisioning configurations
Section data-catalog-provisioning under provisioning-coordinator defines Data Catalog configurations
| Property Name | Default | Type | Meaning |
|---|---|---|---|
is-enabled | false | boolean | When true, the Data Catalog service is called by the coordinator after provisioning operations such as deploy, undeploy, update ACL, according to the Data Catalog Plugin API specification |
Forwardable HTTP headers
To fulfill some of the functionalities it exposes through the REST APIs, the Coordinator relies on services provided by
other systems in the witboost ecosystem. For example, the Coordinator handles a provisioning request received through
its /deploy endpoint by coordinating with multiple specific provisioners to deploy the components included in the
target deployment unit; then it communicates the provisioning results to
the marketplace-compliant services and to
the data catalog.
The following configurations determine which incoming headers can be forwarded from the Coordinator to the provisioning and validation services (specific provisioners, data catalog, marketplace-compliant services) that it invokes during its operations.
Configuration: provisioning-coordinator/forwardable-http-headers
| Key | Type | Default (if not defined) | Description |
|---|---|---|---|
| filters | list[HeaderFilter] | see Default header filters list below | filters (OR-logic) to select the incoming headers that can be forwarded |
HeaderFilter
| Key | Type | Default (if not defined) | Description |
|---|---|---|---|
| name-regex | string | (none) | regular expression to filter an HTTP header by its name. It will be evaluated as a case insensitive regex |
Default header filters list
[
{
name-regex = "^authorization$" // name is "authorization" (case insensitive)
},
{
name-regex = "^wb-user-" // name starts with "wb-user-" (case insensitive)
}
]
By using these default filters, the Coordinator will forward both authorization headers and headers whose name starts
with wb-user-. For example, if the Coordinator receives a /deploy request with the following headers
Authorization: Bearer <token>wb-user-header-1: value-1wb-USER-header-2: value-2
each HTTP request from the Coordinator to the provisioning services will include headers
authorization: Bearer <token>wb-user-header-1: value-1wb-user-header-2: value-2
HTTP headers are case insensitive
Specific provisioner version prefix
Specific provisioner interface specification has changed, introducing endpoint versions and additional endpoints (like
async validation), to maintain retrocompatibility the coordinator calls version-less endpoint. These endpoints will be
deprecated in future versions though. Setting this configuration specific-provisioner-path-prefix enables to specify
the specific provisioner endpoint version for the old version-less endpoints.
| Property Name | Default | Type | Meaning |
|---|---|---|---|
specific-provisioner-path-prefix | string | When empty, the coordinator calls the deprecated specific provisioner endpoint without version. To enable the new endpoint, set the value as v1 |
Computational Governance Platform
Configurations to shape the interaction between the coordinator and the computational governance platform.
Defined under provisioning-coordinator/governance-platform
| Key | Type | Default (if not defined) | Description |
|---|---|---|---|
| provisioning-evaluation-report-label | string | deployment | label to be attached to evaluation reports generated during a provisioning operation. It is used for statistical purposes. |
Events configuration
The provisioning-coordinator.events section contains all configuration properties needed by the Provisioning Coordinator to send
events to the witboost events plugin.
| Property Name | Type | Meaning |
|---|---|---|
is-enabled | boolean | If true enables the events generation from the Provisioning Coordinator |
events-backend-base-url | string | It is the base URL of the events backend service that is installed on the witboost events plugin. This is a combination of the UI module base URL and '/api/events' |
Other configurations
Here some other useful configurations for TLS, HTTP request timeout, URLs e so on.
| Property Name | Default | Type | Meaning |
|---|---|---|---|
http-port | 8088 | int | The port of the Provisioning Coordinator. |
functions-invocation-timeout | 10 minutes | minutes | Maximum execution time for an execution plan task |
microservices-invocation-timeout | 120 seconds | seconds | The time that the HTTP request for the Marketplace Proxy has to await before going in timeout |
scheduler-execution-timeout | 30 minutes | minutes | Maximum execution time for an operation running on the scheduler (i.e. deploy, undeploy, reverse provisioning, etc) before it is aborted |
terminate-dangling-plans-at-startup | true | bool | Whether to transition all the dangling plans to the TERMINATED status when starting the application. Dangling plans are execution plans that are no longer handled by any running scheduler instance (hence, they can be considered as aborted); this situation could be caused by application crashes or forced shutdowns |
provisioning-plan-repository-class | (none) | string | The name of the Scala class used to communicate with the provisioning_task table |
validator-repository-class | (none) | string | The name of the Scala class used to communicate with 'validation_policies' table |
synchronous-validation-timeout | 120 seconds | seconds | Maximum time a provisioning operation can wait for synchronous validation results before throwing an error |
validator-cue-path | (none) | string | The path of the folder where the Provisioning Coordinator can find the CUE files |
provisioner-registry-class | (none) | string | The Scala class used to obtain the Specific Provisioner URL given a component ID |
template-metadata-class | (none) | string | The class used as repository for template_metadata table |
data-product-descriptor-validator-class | (none) | string | The class used as validator for a Data Product descriptor |
supported-kinds | (none) | list[string] | List of supported deployment unit kinds (kind property in the descriptor). If not provided, all kinds are supported |
default-taxonomy | value: urn:dmb:data-mesh-taxonomy | object | An object representing the default taxonomy to save in the database when a deploy is triggered. This value is inserted only if the descriptor has no taxonomy inside of it. |
client-certificate-path | (none) | string | The path to the file that contains the client SSL certificate |
client-certificate-password | (none) | string | The client SSL password |
client-server-certificate-no-check | false | bool | If false, it skip the check for SSL client |
server-certificate-path | (none) | string | The path to the file that contains the SSL certificate server-side |
server-certificate-password | (none) | string | The password of SSL server certificate |
server-tls-on | (none) | string | If false it doesn't allow TLS on Provisioning Coordinator start |
All these properties must be defined under provisioning-coordinator.