These serivces handle running/stopping Projects, copying files, etc. They are the glue between what happens in Kubernetes and in the Database.

  • manage-action: triggered when a project is told to start, stop, restart, etc. Usually, the user is requesting to start a project, which is recorded in the database as a request to start the project. This microservice uses Postgres’s LISTEN/NOTIFY capability to listen for and react to such requests and actually starts the project. Behind the scenes, manage-action not only reads the database, but also the project-pod and project-image ConfigMaps to determine what to do. After compiling all the available information, it sends a Pod configuration to the Kubernetes API server, which then starts the project.

  • manage-state: this service listens to the k8s API for changes regarding projects and updates the database accordingly. It’s the companion of manage-action. In particular, once a project pod is started, it will update the database. This tells the user that the project is running and shortly it will connect. Also, the hub services will connect to that project to establish a communication channel.

  • manage-idle: periodically check if projects are idle and stop them. This also checks if there are any stopped “always running” projects that should be running and starts them, and checks if projects are stuck in pending, and stops them (cleanup).

  • manage-copy: this watches the copy_paths table of the database for requests to copy files, then starts projects if necessary and issues copy operations between projects, and finally writes out the status to the database. This basically issues rate-limited rsync operations.

  • manage-share: similar to manage-copy, but for shared files.

Restart all manage services via:

kubectl rollout restart deploy -l group=manage

or one by one via:

kubectl rollout restart deploy manage-action