Possible configuration tweaks

[esune]

I like the new convention that uses generic service names for builds and deployments, rather than implementation-specific names. It is much easier to understand at a glance, and therefore makes it easier to figure out where to look for troubleshooting.

Prefixes vs. Suffixes

Prefixing vs. suffixing names: this can just be my personal preference, but I think it reads better if we prefix the deployment names (e.g.: indy-cat-api rather than api-indy-cat). Another reason for this is that the pr-based pipeline will add suffixes to deployments as well, so prefixing may make things - again - more readable.

Labeling

1. Deployment groupings: splitting long-lived tools (e.g.: backup container, schema-spy) from the applications, both by using the APP_NAME and APP_GROUP labels would be beneficial because:

   • it will visually group the core items of an application together
   • it should come in handy when we implement the pr-based pipeline, since we will likely not want to deploy the tools alongside the main app with every pull request. As an example, the app grouping for a deployment could be indy-catalyst-orgbook for the main components, and indy-catalyst-orgbook-tools for backup and schema-spy. This could be further refined if, as an example, the backup container was used to back-up multiple databases belonging to different instances of the app (not sure if we would have this use case, but it is in theory possible).

2. APP_NAME and APP_GROUP: these labels were introduced to allow for a better logical grouping of services in OpenShift, so that operations (e.g.: delete everything related to a deployment) could be completed in bulk, rather than per-deployment. We should keep this groupings, but we could consider migrating to k8s standard labels as described here. In particular, we could replace APP_GROUP with app.kubernetes.io/part-of (or just part-of) for consistency, and APP_NAME with app.kubernetes.io/component (or just component).

Naming

I know what the service worker does, just wondering if we should make it even more explicit by naming it something like message-queue-worker. This way, if the queue is named message-queue they would also line up nicely together in the UI :wink:

Conclusions

These are my initial thoughts, open to chatting more about them especially if something I said does not make too much sense!

[WadeBarnes]

Re: Prefixes vs. Suffixes

• The ${SUFFIX} is a place holder to support the PR pipeline conventions. It is currently being utilized in a manual fashion to support deploying multiple application instances into the same OpenShift namespace.

[WadeBarnes]

Re: long-lived tools

• I agree with separating the backup-container. I've created a separate issue for the work.
• With something like schema-spy however the database schema for any given application instance could be different, therefore a schema-spy instance per application instance is justified.

[WadeBarnes]

Re: Naming

• Agreed, created a separate issue.

[WadeBarnes]

Re; Labeling (2.)

• Agreed, created a separate issue.