Registry Helm Chart - 3.x.x

The guide here can be used to understand why Registry Helm chart 3.x.x has been designed the way it is. There are also several other pointers to developing Helm chart. The source of the chart is available here.

Several modules that were installed in 2.x.x have been moved to openg2p-commons. Only the ones specific to Registry have been retained in this chart.

Odoo

External database

In the current deployment architecture single instance of PostgreSQL is installed per environment (refer to OpenG2P Commons). This implies that the same PostgreSQL server will house databases from all the modules in that environment, including multiple instances of Registry (if any). In values.yaml default database has been disabled and external database enabled:

postgresql: enabled: false

externalDatabase: create: true

Note that create: true is not really creating the DB - this is perhaps a known issue in Odoo Docker. It expects DB and user name and secret to exist a priori. Hence, we have created posgtes-init.

Modifications to the original Odoo chart

The original Bitnami chart 26.2.9 was modified to suit OpenG2P requirements. While most modifications were about overriding a few templates, there were some changes in charts as well. The new version 26.3.0 is created maintained by OpenG2P. The source code of the chart is available here. The following changes were made:

• Secrets separated - original Odoo Helm chart assumed that the same secret resource of Kubernetes contains keys for both - Postgres admin and database user. However, we would like to keep them separate as several instances of modules may be initialised and it wouldn't be a good practice to add them to the Postgres secret both from a management and security perspective.

- name: POSTGRESQL_CLIENT_POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: {{ .Values.externalDatabase.existingPostgresSecret }}
                  key: {{ include "odoo.databaseSecretPostgresPasswordKey" . }}

• The above change is in deployment.yaml of Odoo chart - a new secret variable called existingPostgresSecret has been defined and accordingly some Odoo templates had to be modified (see section below).

Use of globals

Several global are used in the Registry Helm chart. Strictly speaking, globals are not required and we must try not to use them. However, here, they offer certain convenience. To avoid hard coding of the same value of a param appearing in multiple places in the Helm chart, we use globals which are accessible to the sub-charts.

Overriding Odoo templates

We have used the function tpl to ensure a value is resolved in deployment.yaml of Odoo such that values like .Release.Name can be used. Some of the Odoo templates have been overridden in the Registry chart to enable templating. Refer to _helpers.tpl for details on these overriden templates.

Bootstrap modules

Modules that are pre-installed in Odoo are specified as a hard-coded list in the Registry Helm chart:

 ODOO_BOOTSTRAP_MODULES: >-
      base,
      g2p_app_filter,
      g2p_auth_oidc,
      g2p_auth_oidc_keycloak,
      g2p_registry

Docker

Odoo Docker is packaged using the scripts in openg2p-packaging repo.

• WAIT_FOR_PROGRESS: This is passed from values.yaml to a wait-for-psql.py script before starting the Odoo Docker. If set to '-1', the script will not wait.

• The conf file passed on to Odoo may be found inside the Docker at /etc/odoo/odoo.conf. You may 'enter' the Odoo Docker from Rancher - by executing shell for the Odoo Pod.

• Odoo Docker can take up to 8-10 minutes to come up as it creates several tables in the database.

Postgres-init

In the previous Helm chart (2.x.x) the initialization of DB was part of the Odoo installation where the DB for Odoo was initialized as part of the Postgres installation in Odoo's Helm chart. For external database, we now have to initialise the DB, create the user and password. Refer to Docker of postgres-init and its Helm chart here. This is a general purpose Helm chart and can be used across modules. The functionality implemented are limited to the following:

• Creation of a DB in an existing Postgres server

• Creation of DB user

• Creation of DB user secret with password

The script is idempotent - which means if we run the init again, and if the database, user exist, it won't touch anything and just exit.

The database user secret created by this chart is set to 'keep' mode such that it doesn't get deleted if the Helm in uninstalled. This is important 'cause even if the Helm chart is uninstalled the database still exists in Postgres, and therefore the secret must also exist. If you would like to tear down entire Registry clean, refer to the tear down instructions below.

Docker

The postgres-init Docker is published on Docker Hub.

To run the Docker from your machine on the cluster (for development and testing), use the following method:

• Port forward using kubectl to connect to Postgres server on the cluster

• Create an env file like this example. For POSTGRES_HOST give the host name as host.docker.internal otherwise from within Docker localhost won't be recognized.

• Run as given here.

If you would like to update the postgres-init Docker, DO NOT use Mac OS, work on Linux machine otherwise you will run into architecture mismatch issues.

ID Generator and mosip-kernel DB init

The ID Generator requires mosip_kernel database to be created. This is currently created under Registry, but ideally, mosip_kernel could be part of openg2p-commons (TBD).

Background tasks

The bg-tasks installed with this Helm require Redis which is also installed with this chart. We would use one Redis per module instead of installing Redis for every application.

Bg-tasks attempts to connect to Redis till Redis is up. So if you see in the logs ‘unable’ to connect to Redis, it’s fine, as long as ultimately it gets connected.

Running the Registry chart

The chart is available on Rancher. Follow the installation steps.

Tear down

Refer to instructions here.