PBMS Helm Charts

Information regarding helm charts for installation for PBMS and all it's dependencies

G2P PBMS (Odoo + Background Tasks) and all its dependencies can be installed using a single Helm chart which acts the main chart for PBMS Odoo Core (odoo) and references multiple sub-charts.

• openg2p-pbms-bg-task-api

• openg2p-pbms-bg-task-celery-beat-producers

• openg2p-pbms-bg-task-celery-workers

PBMS Core Odoo

The PBMS Core Odoo chart is the primary component of the PBMS Helm deployment. It serves as the main Odoo instance for PBMS and includes references to all Background Task sub-charts (API, Celery Beat Producers, and Celery Workers).

This component deploys the Odoo application container image (openg2p/openg2p-pbms-core) configured with PostgreSQL, Redis, Keycloak for OIDC authentication, and MinIO for object storage.

Key configurations include:

• External PostgreSQL connection (externalDatabase) linked to pbmsdb.

• OIDC integration using Keycloak (oidcIssuerUrl, oidcClientId, oidcClientSecret).

• Environment variables controlling performance, logging, and module behavior.

• Integration with MinIO (S3_URL, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY) for media and file storage.

• Redis service used as a broker for job queues and cache.

• Optional Istio VirtualService configuration for routing traffic to Odoo.

PBMS Background Tasks API

The PBMS Background Tasks API sub-chart deploys the API service responsible for managing and exposing background task endpoints. It provides an interface layer between PBMS and the asynchronous processing system, handling requests from Odoo and passing task metadata to Celery producers and workers.

Key configurations include:

• Uses the PostgreSQL instance defined in the global configuration.

• Connects to both the Background Task Database (bgtaskdb) and Social Registry Database (registrydb).

• Configured via environment variables such as:

  • BG_TASK_API_DB_HOSTNAME, BG_TASK_API_DB_DBNAME, BG_TASK_API_DB_USERNAME for the Background Task DB.

  • BG_TASK_API_DB_HOSTNAME_SR, BG_TASK_API_DB_DBNAME_SR, BG_TASK_API_DB_USERNAME_SR for the Social Registry DB.

• Integrates with Keymanager for secure key operations if required.

PBMS Background Tasks Celery Beat Producers

The PBMS Background Tasks Celery Beat Producers sub-chart is responsible for scheduling and triggering periodic background tasks. It acts as the “heartbeat” of the background task system, periodically generating task events for Celery Workers to process.

Key configurations include:

• Frequency, batch size, and concurrency are controlled by environment variables:

  • BG_TASK_CELERY_BEAT_PRODUCER_FREQUENCY

  • BG_TASK_CELERY_BEAT_BATCH_SIZE

  • BG_TASK_CELERY_BEAT_NO_OF_TASKS_TO_PROCESS

• Connects to multiple databases:

  • PBMS Core DB (pbmsdb)

  • Background Task DB (bgtaskdb)

  • Social Registry DB (registrydb)

• Uses Redis as the Celery broker and backend:

  • BG_TASK_CELERY_BEAT_CELERY_BROKER_URL

  • BG_TASK_CELERY_BEAT_CELERY_BACKEND_URL

This component ensures continuous and reliable task dispatching to maintain workflow execution in the PBMS ecosystem.

PBMS Background Tasks Celery Workers

The PBMS Background Tasks Celery Workers sub-chart handles asynchronous execution of the tasks generated by Celery Beat Producers and the API. Each worker consumes jobs from the Redis queue and performs operations such as data synchronization, eligibility computation, and background updates.

Key configurations include:

• Batch and concurrency control: BG_TASK_CELERY_WORKERS_BATCH_SIZE.

• Multi-database connectivity:

  • PBMS DB, Background Task DB, Social Registry DB, and asynchronous Postgres connections (postgresql+asyncpg).

• Redis as Celery’s broker and backend for reliable task delivery and tracking.

• Keymanager integration for cryptographic operations (e.g., signing keys, secure access tokens).

Environment variables manage:

• Async DB connection (BG_TASK_CELERY_WORKERS_DB_DRIVER_ASYNC, BG_TASK_CELERY_WORKERS_DB_USERNAME_ASYNC).

• Security and Keymanager access (BG_TASK_CELERY_WORKERS_SIGN_KEY_KEYMANAGER_APP_ID, BG_TASK_CELERY_WORKERS_KEYMANAGER_API_BASE_URL, etc.).

Database

The PBMS Helm chart provisions a shared PostgreSQL instance used by both the PBMS Core Odoo and Background Tasks components. The database runs in the same Kubernetes namespace as the application stack and is automatically initialized via the postgres-init job. This ensures that all required databases, users, and secrets are created before Odoo and Background Task pods start.

Two distinct databases are configured for separation of concerns:

• pbmsdb — the primary database for the PBMS Odoo instance.

• bgtaskdb — the dedicated database for Background Task components (API, Celery Beat Producers, and Celery Workers).

Database connection details, usernames, and secrets are defined under the global values section in the Helm chart and templated per release using Helm’s tpl function. Key parameters include:

• Global DB variables

  • global.postgresqlHost: internal PostgreSQL service hostname (e.g., openg2p-commons-postgresql)

  • global.pbmsDB, global.pbmsDBUser, global.pbmsDBSecret, global.pbmsDBUserPasswordKey: for the Odoo database

  • global.pbmsBgTaskDB, global.pbmsBgTaskDBUser, global.pbmsBgTaskDBSecret, global.pbmsBgTaskDBUserPasswordKey: for the Background Tasks database

• Database initialization (postgres-init)

  • Automatically provisions both pbmsdb and bgtaskdb with corresponding users.

  • References the global secret templates for credential management:

    - name: '{{ tpl .Values.global.pbmsDB $ }}'
      user: '{{ tpl .Values.global.pbmsDBUser $ }}'
      secret: '{{ tpl .Values.global.pbmsDBSecret $ }}'
    - name: '{{ .Release.Name }}_bgtask_db'
      user: '{{ .Release.Name }}_bgtask_db_user'
      secret: '{{ .Release.Name }}-bgtask'

  • The root PostgreSQL password is read from the existing secret openg2p-commons-postgresql.

All PBMS components — Odoo, API, Celery Beat Producers, and Celery Workers — connect to PostgreSQL using these templated credentials via their respective envVars sections. This allows consistent configuration and automatic secret injection across sub-charts.

By maintaining separate databases under a shared PostgreSQL service, the Helm chart provides both operational isolation (between synchronous and asynchronous workloads) and deployment simplicity, while leveraging Kubernetes Secrets for secure credential management.