k5-project configuration
Introduction
The k5-project configuration provides configurations that apply to all new deployments within a k5-project. It is meant as a default configuration for deployments that can be overwritten by a deployment configuration.
New service bindings can only be created within the k5-project configuration.
This configuration has to be done for each new k5-project.
You can find the k5-project configuration in Solution Hub after you selected a project.
Alternatively, you can do the settings via a REST API called Configuration Management API ( see API documentation). This API provides a Swagger UI for ease-of-use but you can use the tool of your choice for calling APIs (e.g. cURL, Postman).
As long as not configured otherwise, the default URL where you can find the Configuration Management Swagger UI is built like this:
https://k5-configuration-<namespace>.apps.openshift-cluster.mydomain.cloudThe exact URL can be found within the route named k5-configuration-management. It can be easily retrieved by executing
oc get route k5-configuration-management -n <namespace>whereby <namespace> points to the namespace, where IBM Industry Solutions Workbench is installed (e.g. k5-tools)..
See deployment configuration if you want to change the settings for a specific deployment.
The k5-project configuration tab provides the following categories of settings:
- Authentication
- Database
- Features
- Logging
- Messaging
- Operations
- Testing
Authentication
Identity provider service binding:
Select an existing service binding from the list or create a new binding for the identity provider.
| Form Field | Description |
|---|---|
| Name | Specify a unique name for this binding. |
| Client Id | The client ID of a registered OAuth client |
| Client Secret | The secret value which is bound to the referenced OAuth client. |
| Issuer | The issuer which has issued the JWT. |
| JWK URI | The URL of the JSON Web Key (JWK) set. |
| User Authorization URI | The URL of the OAuth authorization endpoint. |
| Token URI | The URL of the OAuth token endpoint. |
Database
Database service binding:
Select an existing service binding from the list or create a new binding for the database connection.
| Form Field | Description |
|---|---|
| Name | Specify a unique name for this binding. |
| Database URI | The MongoDB connection string |
Example:
mongodb://username:password@mongodb.domain.svc.cluster.local:27017/admin?ssl=falseFeatures
Enable usage of DEV bindings:
Defines that deployments can use DEV bindings, that are defined in Solution Designer if no service binding was specified in the Configuration Management.
Enable CORS:
Defines if Cross-Origin Resource Sharing is enabled or not.
Publish internal helper API:
Defines if the internal helper API of a deployment is exposed within the Swagger UI.
Logging
Log level of the domain server:
Adjust the log level configuration used for the domain server. This can be one of the following values:
ALLDEBUGINFOWARNERRORFATALTRACE
Log level of deployments:
Set the default log level for the deployments.
You can set the log level for a specific path by creating a key/value pair for it. Enter the path to the files for which you want to set the log level into the left column and select the desired log level from the drop-down menu in the right column. Then click on the "+" sign to save this entry.
Messaging
Message hub binding:
Select an existing service binding from the list or create a new binding for the message hub.
| Form Field | Description |
|---|---|
| bindingName | Specify a unique name for this binding. |
| kafka_brokers_sasl | The URL(s) of the bootstrap broker(s). |
| user | The provided Kafka user must have the permission to read and create topics. |
| password | Enter the password for the specified message hub user. |
| saslMechanism | Select the SASL mechanism to use with the message hub. |
| saslJaasConfigLoginModuleQualifiedName | The SASL JAAS Config Login Module used for the SASL mechanism. This field will be auto-filled depending on the selected SASL mechanism. |
Enable audit trail:
Defines if deployments shall send events to a project-wide topic that records all access to any data.
Schema Registry
The Schema Registry provides a shared repository of schema definitions. Those schema definitions are used in events to describe their payload and therefore define a reliable contract between event producers and consumers.
In order to setup the Schema Registry integration, please add the secrets k5-schema-registry-binding and k5-schema-registry-oauth-secret to the deployment target using the below key-value pairs:
k5-schema-registry-binding
| Key | Value |
|---|---|
| url | Schema Registry url |
| securityEnabled | Boolean indicating whether security is enabled for the Schema Registry. If yes, more data for authentication will have to be provided |
k5-schema-registry-oauth-secret (only needed if k5-schema-registry-binding.securityEnabled is true)
| Key | Value |
|---|---|
| baseurl | Base url of Schema Registry authentication server |
| realm | Schema Registry authentication realm |
| client.id | Schema Registry client id |
| client.secret | Schema Registry client secret |
Operations
Automatic horizontal scaling:
Defines whether automatic horizontal scaling of the deployment is enabled or not.
Target CPU utilization:
Defines at with CPU usage percentage an additional pod will be started.
Min. number of pods:
Set the minimum number of running pods (1-100).
Max. number of pods:
Set the maximum number of running pods (1-100). Has to be greater or equal to Min. Number of Pods value.
Testing
Enable testing support:
Defines if an additional API for testing is available. If disabled, integration tests within the pipeline are not possible.
Activation of this feature is not recommended for PROD-deployments.
Username (default user for testing):
Default username used for executing the deployment tests (e.g. dev-envoy-test-user).
Password (default user for testing):
Password used for the specified default user for executing the deployment tests.