Dashboard Template - Settings

[lotharking]

Dashboard templates

Template files are those used for constructing various components. These files are categorized into the following types:

• Deployment Templates (template.yml)
• Environment Variables (values.yml)
• Fastbot Templates (config.yml)
• Schema Repository (schema_dir.json)

Files Structure

The expected file distribution will be maintained as follows:

- Fastbot
  * template.yml
  * values.yml
  * README.md
  - Setup
    * config.yml
    * schema_dir.yml
- Email
  * template.yml
  * values.yml
  * README.md
- Biometric
  * template.yml
  * values.yml
  * README.md

Each new Kubernetes template deployed should have its corresponding documentation. This documentation (readme file) will enable services utilizing the templates to effectively locate the necessary information for their deployment and configuration.

---

Note:

• The file distribution for version management in Fastbot is based on the previously proposed structure. Please keep in mind that the schema_dir.json contains all the data related to the validation of Fastbot, including both versioning information and functions.
• The GitHub Actions component's validations will not accept the addition of templates unless they include at least a YAML file and a Markdown file.

---

Deployment Templates

They contain the deployment information in Kubernetes for the different types of chatbots that can be support for Hologram. It is important to keep in mind that each deployment template must contain the following requirements in order to be implemented:

Content

Due to the use of a single deployment file, the following kind must be integrated: Namespace, Service, Ingress, and StatefulSet. The recommended structure resembles the following:

apiVersion:
kind: Namespace
metadata:
---
apiVersion:
kind: Service
metadata:
spec:
---
apiVersion:
kind: Ingress
metadata:
spec:
---
apiVersion:
kind: StatefulSet
metadata:
spec:

Ingress Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ .Values.dtsName }}-public
  namespace: {{ .Values.namespace }}
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - {{ .Values.hostname }}
        - i.{{ .Values.hostname }}
      secretName: public.{{ .Values.hostname }}-cert
  rules:
    - host: {{ .Values.hostname }}
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                 name: {{ .Values.dtsName }}
                 port:
                   number: 3001
    - host: i.{{ .Values.hostname }}
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                 name: {{ .Values.dtsName }}
                 port:
                   number: 80

---

Note:

• In this format, various variations can be handled, such as the creation of ingress according to a specific network, or any other specification allowed within this type.

---

Params

For the parameterization of these files, the considerations provided by the Helm package manager are used. Helm offers the flexibility to construct deployment files with extensive parameterization options. This system even allows for the addition or removal of entire modules in its values file if deemed necessary, making the deployment experience much more customizable for various applied uses.
Example:

Namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: {{ .Values.namespace }}

Values.yaml

namespace: demos-main

---

Note:

• It is important to note that all documentation on how to configure files for proper deployment in Helm can be found in its respective documentation. However, it's crucial to understand that each Helm project consists of three main parts:

---

1. templates folder, which contains valid Kubernetes manifest files.
2. values file, which contains values for this chart.
3. chart file, which contains information about the chart.

For this implementation, a similar structure will be used. The templates files will be unified to include everything related to deployment, and the values file will function normally. The chart file will not be required, as the repository will not be processed directly; instead, individual files will be used.

Environment Variables

This file corresponds to the configuration variables previously defined in template.yaml. It is important to note that variables used in the template file which do not have a corresponding entry in the values.yaml will generate an error and will be reported to the user. However, variables that are not used in the template will not affect the generation of the deployment files.

Example:

dtsName: auth-bank
namespace: demos-dev
hostname: auth-bank.demos.2060.io
replicas: 1
agentName: Modern Bank - Identity Verification
welcomeMessage:
  first: Welcome to Modern Bank - Know Your Customer (KYC) Service.
  second: To get started, use the contextual menu above ↗️ to identify yourself so that you'll be able to access your bank services. If you do not have a Gaia identity Card, choose Get an Identity Card.
  third: Congratulations, you're authenticated! you can now continue with opening your bank account.

Fastbot Templates

This type of template is exclusively valid for use within the Fastbot Service and serves for potential parameterization purposes. According to the official documentation, when creating these templates, it's essential to specify a version that identifies the type of options the system can handle. Further details regarding its creation and considerations are explained in greater detail within the documentation

Validations

The validations applicable to files containing templates for Fastbot deployments must adhere to the rules specified in the schema.json files found in the repository within the templates/config folder, corresponding to their respective version according to the implementation. This ensures consistency across possible implementations

Example:

version: 1.0
optionManage:
  - type: user-manage
    id: ENABLED_AVAILABLE_CMD
    key: /help
  - type: user-manage
    id: ENABLED_AVAILABLE_CMD
  - type: user-manage
    id: ENABLED_INVITATION_CREDENTIAL
    key: welcome
    value:
      type: invitation
      label: Cédula Verificable 🇧🇴 (demo Segip)
      imageUrl: https://q.bolivia.demos.2060.io/avatar.png
      did: did:web:bolivia.demos.2060.io
  - type: service-manage
    id: ENABLED_STEP
    key: welcome
    item:
      - type: text
        content: Hello, welcome to the registration system for Mobiera SAS applicants
      - type: text
        content: Firstly, please send your email credential to begin the identity validation process
      - type: identity-proof-request
        requestedProofItems:
          - type: verifiable-credential
            credentialDefinitionId: did:web:bolivia.demos.2060.io?service=anoncreds&relativeRef=/credDef/Co5UrRrQnuovN5BapF74CUZPL7UxqeCqwPbtsJ9u6eJR
            attributes:
              - citizenId
              - firstname
              - lastname
              - birthdate
              - photo
              - citizenSince

Schema Repository

This directory contains a file that will only be present within the Fastbot template directory. This is because only the Fastbot template needs to specify the versioning type used in the project, which will be applied to the Fastbot configuration file. This file must follow the structure outlined below. It is important to note that this validation schema will be applied at various stages of the process. Therefore, if the file is not valid, GitHub validations will prevent its update.

Example:

{
  "config": {
    "path": "2060-io/fastbot-conversational-schema",
    "branch": "fastbot-1.0"
  }
}

---

General considerations

• The GitHub Actions will conduct comprehensive validations to ensure the integrity and quality of the templates. This includes linting YAML files to maintain consistency and readability, checking adherence to file naming conventions for clarity and organization, as well as verifying parameterization according to specified standards.
• The configuration for GitHub Actions resides in the .github/workflows directory within the repository. It is set up with defined workflows to execute validation processes automatically upon pull requests to the dev and main branches. Detailed configurations can be found in the YAML files within this directory.
• As part of the validation process, the GitHub Actions will perform various file structure validations. These include ensuring the presence of mandatory files such as YAML and Markdown files, confirming the correct directory hierarchy, and validating the consistency of file naming conventions, particularly adhering to camel case directives.

---