StarlingX/Containers/Applications/app-vault
Contents
Application: vault-armada-app
Source
Building
- From the Debian Build environment:
VAULT_PKGS="python3-k8sapp-vault,vault-helm,vault-manager-helm,stx-vault-helm" build-pkgs -c -p $VAULT
The packages contain:
- python3-k8sapp-vault - sysinv integrations; helm and lifecycle
- vault-helm - the build of upstream vault helm chart
- vault-manager-helm - the build of Starlingx vault-manager helm chart
- stx-vault-helm - the Starlingx application; metadata, fluxcd yaml
The final package stx-vault-helm contains the output of the others. The stx-vault-helm package is installed on the ISO. The installed application tarball is '/usr/local/share/applications/helm/vault-*.tgz'
Testing
Vault sanity should typically include:
- application lifecycle: upload, apply, remove, abort, delete, update, and helm overrides
- Vault with replicas=1 (AIO-SX) and replicas=3 (AIO-DX + worker or standard controller)
- Configure vault with CLI and REST API
- Workflow for applications that are Vault aware (REST API) and unaware (vault injector)
- Pod recovery
- Vault backup and restore
- Vault-manager features including: rekey, PVC conversion (upgrade)
- Download images from private registry; network isolation test
Application Lifecycle
Refer to Application Commands and Helm Overrides Typically changes for the following should be accompanied with testing for the application lifecycle:
- Sysinv integrations, package python3-k8sapp-vault
- New and updated helm charts or chart overrides (values.yaml)
And also at the end of each release cycle the sanity for application lifecycle should be asserted.
Vault with replicas 1 and 3
When the vault app is applied on AIO-SX, the vault server statefulset is configured automatically with replicas=1. When there are three or more controller and worker nodes provisioned in the cluster then the vault server statefulset will be configured automatically with replicas=3.
Sanity for replicas=3 should include vault HA - observation that a standby vault server becomes active when the active server is restarted gracefully.
Refer also to "Pod Recovery" section.
