Add support to startup routine to allow for Orthanc instance to register with "Imaging Servers" if not already defined
Currently, the process for deploying an imaging server is multi-stepped. It requires:
- Creating a
SonadorImagingServer
with all of the defined connection parameters so that it is possible to get a "server ID." - Using the Sonador imaging server data to create an Orthanc configuration
- Deploying the Orthanc server
- Making adjustments to the Sonador configuration (if required) after deployment
- API endpoint requires admin/super-user permissions
If a change is needed (like a modified hostname or scheme), components must be modified manually and re-deployed. Feedback from systems administrators indicates that the process is too complex and needs to be modified.
Requirements:
- Expose an API that allows for Orthanc instances (via the Sonador plugin) to create (or modify) the details of their configuration.
- Add logic to the Sonador plugin which allows for the Sonador plugin to register the server (including the server ID, which serves as primary key in the Orthanc database as part of startup)
- After a server has been first registered (created), it is not possible to modify the configuration
Configuration:
- Make the Orthanc configuration the canonical record of the server's connection parameters
- server name: name used to identify the server within Sonador
- hostname (external) hostname for the server
- port (external): port that should be used for connecting to the server
- control scheme (external): control scheme for the server
- internal hostname (optional): internal/Kubernetes hostname for the server
- internal port (optional): internal/kubernetes (service) port
- internal control scheme (optional): internal control scheme
Implementation
Edited by Rob Oakes