[Leer en español](README_es.md)

# Design decisions of the chart

This README explains some of the design decisions made during the development of the `helm` chart.

## Usage of Namespace

The namespace `exam` is used to isolate the resources (with all the benefits that brings) and avoid using the `default` namespace.

## Usage of Default Values

All variables that are repeated and that, initially, wouldn't make sense to change for this chart are marked with default values.

For example, look for the defaults in `service.yaml`. You'll see that `type` defaults to "ClusterIP" and `targetPort` defaults to `$port`.

This has two benefits:

1) Reduces redundancy in `values.yaml`.
2) Provides freedom to easily modify it in the future in `values.yaml`. For example, suppose we want to change the `type` to "NodePort" in the `api` service, it's sufficient to make the following change:

```yaml
services:
  - api:
    name: "api"
    tier: "backend"
    port: 5000
    type: "NodePort"
```

## Flexibility with Domain

In `ingress`, the `host` is repeated to facilitate the API being on another domain. For example:

```yaml
ingress:
  ssl: true
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  hosts:
    - host: kube.slc.ar
      paths:
        - path: /
          name: "client"
          port: 8080
          pathType: "Prefix"
    - host: api.kube.slc.ar
        - path: /
          name: "api"
          port: 5000
          pathType: "Prefix"
  tls:
   - secretName: exam-crt
     hosts:
       - kube.slc.ar
       - api.kube.slc.ar
```

## Certificates for Ingress

Autogenerated certificates can be passed in `ingress.ssl.*`, BUT note the security restrictions of `helm`: only files relative to the chart path can be used. Therefore, if you want to use a file from "outside," you can create a symbolic link. For example: `cd helm && ln -sf /usr/local/etc/ssl/certs/ca.crt ca.crt && ln -sf /usr/local/etc/ssl/private/ca.key ca.key`. Then, pass those files to `ingress.ssl.*`.

Note that for these secrets to be used:
1) If `secret-crt` already existed, it must be deleted and a `helm upgrade` performed.
2) If it didn't exist, a `helm install` is sufficient (or even a `helm upgrade` if it was already running).

Therefore, suppose you want to update the certificates with ones autogenerated by you (and to update them once the ones autogenerated by you expire). The steps are as follows:

1) Delete `exam-crt`.
2) Update certificates.
3) Put them in the `values.yaml` if the path has been modified or if a helm-autogenerated one was used before.
4) Perform `helm upgrade`.

If you want to update the ones autogenerated by helm, the steps are:

1) Delete `exam-crt`.
2) Perform `helm upgrade`.

Note that if you only perform an upgrade, the `exam-crt` will not be regenerated. This is expected because otherwise, every time we modify something, a new certificate would be autogenerated!

## Stateful for Postgres

Choosing to implement a `stateful.yaml` file as we need PostgreSQL to be an application with "stable, persistent storage" (see [documentation](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#using-statefulsets)). Additionally, in the future, if we wanted to have READ replicas, it could be done very easily by adding containers and necessary logic. For that case, a stateful set must be used to always keep the master identified. I left it as more of a future-proofing measure.

Note that if we were using a deployment, we would have many problems with the application's `stop` because they are sharing the same data volume at the same time (until the new pod is successfully up, the old one will remain active and then stop). This could lead to corruption of the database. This problem is easily fixed with a StatefulSet.

On the other hand, if we were using a cluster, `RollingUpdate` would save us from an image that does not exist, for example, as it starts with the pods with the highest cardinal and if one fails, it doesn't continue updating.

## Connection Tests

They can be run with `helm test exam -n exam`.