Miscellaneous

  • hub.deleteProjectsIntervalH: there is a dedicated service to “unlink” a project, that has been marked as being deleted. The data itself is retained, though. You have to periodically check up in the database, which projects are deleted and remove the associated files.

  • hub.debug, manage.debug, manage.project.debug, …: tweak the $DEBUG variable used with Debug JS, in order to control how much information is logged to the Pods.

  • ssh-gateway.recent_projects: to make a project start automatically when connecting via the SSH Gateway, there must be a prepared entry for the project – a limitation of how this is implemented. This setting controls how many projects are considered as “recent” and hence are prepared for that. Increase this to e.g. 1 year, if you do not have many projects – i.e. more than 1000 per year. Otherwise, you have to start the project first, wait up to loop_delay_secs, and then try to connect via SSH.

Conat Persistence Backend

The hub.persist section controls how Conat stores its persistent data. There are two backends:

  • hub.persist.backend: "nfs" (default): uses a subPath on the shared NFS PVC for project data. Simple and requires no extra setup.

  • hub.persist.backend: "disk": uses a dedicated ReadWriteOnce PVC (SSD recommended). Better I/O performance for larger deployments.

When using disk mode, additional settings are available:

hub:
  persist:
    backend: "disk"
    claimName: "hub-conat-persist"  # PVC name (chart creates it)
    storageClass: ""                # your storage class
    size: "100Gi"

The hub.persist.replicas setting (default: 2) controls the number of persist server processes running inside the single hub-conat-persist pod. They use hash-based sharding to distribute load. Per-process resources are configured via hub.persist.resourcesPerReplica.