Unmanaged Orchestrator

Warning

This feature is currently in beta. It may change in a future version without prior notice. See the Beta Features page for the full list of beta features and their planned release. If you’re using this feature, we encourage you to share your feedback to help with the evaluation process.

This installation type is intended for users who want full control over the application at the orchestration level. It is reserved for users who are comfortable with configuring microservice orchestrators.

In this mode, the full lifecycle management of modules is delegated to the integrator. This includes installation, updates, and removal—even when a new configuration becomes available.

Installation

1. Create the admin user secret

   You can use any type of Kubernetes secret, as long as it is mounted at the expected path.

   The default setup expects a secret named admin-login, containing a password entry.

   For more about creating and managing secrets, refer to the Kubernetes Secret documentation.

   apiVersion: v1
   kind: Secret
   metadata:
       name: admin-login
   type: Opaque
   data:
       username: <base64-encoded-username>
       password: <base64-encoded-password>
   

   Hint

   You can download both admin-login and database-login on this link and apply it using kubectl.

   It is also possible to create and apply this secret using this command (development purposes):

   kubectl create secret generic admin-login --from-literal=password=mynotsosecretpassword --from-literal=username=admin
   

2. Create the database login secret (Keycloak - MySQL)

   Keycloak and MySQL must share a secret containing the database password:

   kind: Secret
   apiVersion: v1
   metadata:
       name: database-login
   data:
       keycloak-password: <base64-encoded-password>
   type: Opaque
   

   Hint

   You can download both admin-login and database-login on this link and apply it using kubectl.

   It is also possible to create and apply this secret using this command (development purposes):

   kubectl create secret generic database-login --from-literal=keycloak-password=swissdotnetswissdotnet
   

3. Download and apply OnSphere’s default deployment

   Download the initial osp-dispatcher manifest and apply it using kubectl.

   Note

   The manifest file must be adapted to your environment:

   • Replace any volume or secret names prefixed with default with the actual namespace name. This is a legacy limitation that will be resolved in future releases.

   kubectl apply -f <file-downloaded-path> -n default
   

   Once applied, the dispatcher will start. Git access will soon be available to clone your configuration and begin integration.

   REMINDER: Every module must be manually created from a deployment, along with the corresponding services.

4. Add module configuration

   Most of modules excepted osp-configuration-dispatcher are now probably in error state because they are not expected to be alive. Their configuration has to be added in git configuration:

   git clone ssh://osp@<ip:port-of-loadbalancer>/git/onsphere.git /tmp/onsphere/
   cd /tmp/onsphere
   git checkout edit
   git checkout origin/osp-default-configuration .
   git checkout origin/osp-web-configuration .
   git add .
   git commit -m 'Commit message !'
   git push
   

   Due to current limitation, the module osp-configuration-dispatcher may need a restart after the initial push.

   Check for a need to restart by verifying logs:

   $ kubectl logs pod/modules-configuration-dispatcher-main-...
   
   2025-07-02 11:55:35.673 [osp-configuration-dispatcher services] INFO  c.s.o.d.f.rabbit.RabbitMQManagement - Failed to update RabbitMQ user list: [RetryableException | Connection refused executing GET http://rabbit:15672/api/users].
   

   In case the dispatcher is looping on try to log into rabbit, restart it:

   kubectl rollout restart deployment.apps/modules-configuration-dispatcher-main
   

   After a few seconds, all modules should retry and be able to retrieve their configurations.