DiracX Extension (BelleRawDiracX)

[dhrjklt]

• In our current DIRAC extension (BelleRawDIRAC), we have a single service with methods that perform service locks at the service level to prevent race conditions when multiple identical agents try to access the same table.
  Since DiracX requires scaling the backend pods (meaning identical pods will serve the same request), could you recommend how to implement service locking in a scenario where multiple DiracX backend pods are running?

In DiracX, diracx-tasks will replace the current DIRAC agents and run inside Kubernetes. In our BelleRawDIRAC extension, some of these agents need to perform read/write operations on the high-performance shared file system (IBM GPFS).

• Question: If a diracx-tasks runs as a pod, how can it access the shared file system?

• Is it possible to run diracx-tasks outside Kubernetes ?

Using an NFS mount inside pods is not a viable solution, as it would significantly reduce throughput.

One option is the Kubernetes local-path CSI plugin, but this comes with restrictions on write permissions to the shared file system.

Another possibility is to interface the IBM GPFS CSI plugin with Kubernetes. However, this would require additional effort and support from the KEKCC administrators.

[chaen]

Hi,

For your locking issue, you have 2 approaches:

• use the kubernetes concept of statefullset which ensures some sort of uniqueness and persistence
• Move the locking/assignment mechanism to the DB, which is most probably what you should do.

For the diracx-tasks, given that we haven't yet finished designing it, I will not commit on anything, but we recognize the need for a non kubernetes solution.
Regarding the external storage, this is really an infrastructure specific issue, and we are not in the best position to give advice here, but definitely the GPFS CSI plugin is the cleanest way to do.

[dhrjklt]

Thanks for the suggestions.

Yes, moving the locking/assignment to the database is the cleanest approach, and I will look into both options.

Regarding external storage, we understand that this is infrastructure-specific. We are exploring possibilities for a stable setup, but for our extension deployment, we plan to use persistent volume for centralized logging and MySQL.