You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we are using SSH to update the cscreen config on the cscreen server. SSH connects are quite hard to properly implement and clean up in Python if anything related to the network happens. Furthermore, it is at the moment required to login to the server as a user that can restart the cscreend systemd service.
These challenges led me to the idea of having a micro-service that actively polls a boolean endpoint at the Orthos 2 server which tells the microservice to update the cscreen configuration file and restart the daemon. The information for this operation can be retrieved via the REST API from Orthos2.
What advantages are there with the microservice:
The cscreen server doesn't have to be accessible via SSH by Orthos.
cscreen may be moved into a container, meaning the microservice can run in a dedicated sidecar.
On a bare-metal deployment the microservice can get the rights to restart the systemd service via policykit.
The microservice can attempt to avoid using Django (or Python altogether) to reduce the number of dependencies.
Currently, we are using SSH to update the cscreen config on the cscreen server. SSH connects are quite hard to properly implement and clean up in Python if anything related to the network happens. Furthermore, it is at the moment required to login to the server as a user that can restart the cscreend systemd service.
These challenges led me to the idea of having a micro-service that actively polls a boolean endpoint at the Orthos 2 server which tells the microservice to update the cscreen configuration file and restart the daemon. The information for this operation can be retrieved via the REST API from Orthos2.
What advantages are there with the microservice:
The text was updated successfully, but these errors were encountered: