{"id":19601515,"url":"https://github.com/stackstorm/stackstorm-k8s","last_synced_at":"2025-04-04T18:05:00.945Z","repository":{"id":38389657,"uuid":"147727013","full_name":"StackStorm/stackstorm-k8s","owner":"StackStorm","description":"K8s Helm Chart that codifies StackStorm (aka \"IFTTT for Ops\" https://stackstorm.com/) Highly Availability fleet as a simple to use reproducible infrastructure-as-code app","archived":false,"fork":false,"pushed_at":"2024-12-16T22:22:49.000Z","size":7806,"stargazers_count":107,"open_issues_count":46,"forks_count":109,"subscribers_count":18,"default_branch":"master","last_synced_at":"2025-03-28T17:06:06.837Z","etag":null,"topics":["containers","docker","foss","ha","helm","helm-chart","helm-charts","high-availability","k8s","k8s-cluster","kubernetes","st2","stackstorm","stackstorm-cluster","stackstorm-ha"],"latest_commit_sha":null,"homepage":"https://helm.stackstorm.com/","language":"Smarty","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/StackStorm.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"community_bridge":"stackstorm"}},"created_at":"2018-09-06T20:02:06.000Z","updated_at":"2025-01-26T15:51:47.000Z","dependencies_parsed_at":"2023-11-23T22:27:24.400Z","dependency_job_id":"4e61f943-374f-4a56-9101-e80adb73aea8","html_url":"https://github.com/StackStorm/stackstorm-k8s","commit_stats":null,"previous_names":["stackstorm/stackstorm-ha"],"tags_count":43,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StackStorm%2Fstackstorm-k8s","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StackStorm%2Fstackstorm-k8s/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StackStorm%2Fstackstorm-k8s/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StackStorm%2Fstackstorm-k8s/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/StackStorm","download_url":"https://codeload.github.com/StackStorm/stackstorm-k8s/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247226213,"owners_count":20904465,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["containers","docker","foss","ha","helm","helm-chart","helm-charts","high-availability","k8s","k8s-cluster","kubernetes","st2","stackstorm","stackstorm-cluster","stackstorm-ha"],"created_at":"2024-11-11T09:18:44.142Z","updated_at":"2025-04-04T18:05:00.919Z","avatar_url":"https://github.com/StackStorm.png","language":"Smarty","readme":"# `stackstorm-ha` Helm Chart\n[![Build Status](https://circleci.com/gh/StackStorm/stackstorm-k8s/tree/master.svg?style=shield)](https://circleci.com/gh/StackStorm/stackstorm-k8s)\n[![E2E Tests](https://github.com/StackStorm/stackstorm-k8s/actions/workflows/e2e.yaml/badge.svg)](https://github.com/StackStorm/stackstorm-k8s/actions/workflows/e2e.yaml)\n[![Lint](https://github.com/StackStorm/stackstorm-k8s/actions/workflows/lint.yaml/badge.svg)](https://github.com/StackStorm/stackstorm-k8s/actions/workflows/lint.yaml)\n[![Unit Tests](https://github.com/StackStorm/stackstorm-k8s/actions/workflows/unit.yaml/badge.svg)](https://github.com/StackStorm/stackstorm-k8s/actions/workflows/unit.yaml)\n[![Artifact HUB](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/stackstorm-ha)](https://artifacthub.io/packages/helm/stackstorm/stackstorm-ha)\n\nK8s Helm Chart for running StackStorm cluster in HA mode.\n\nIt will install 2 replicas for each component of StackStorm microservices for redundancy, as well as backends like\nRabbitMQ HA, MongoDB HA Replicaset and Redis cluster that st2 replies on for MQ, DB and distributed coordination respectively.\n\nIt's more than welcome to fine-tune each component settings to fit specific availability/scalability demands.\n\n## Requirements\n* [Supported](https://kubernetes.io/releases/) [Kubernetes](https://kubernetes.io/docs/setup/) cluster\n* [Helm](https://docs.helm.sh/using_helm/#install-helm) `v3.5` or greater\n\n## Usage\n1) Edit `values.yaml` with configuration for the StackStorm HA K8s cluster.\n\u003e NB! It's highly recommended to set your own secrets as file contains unsafe defaults like self-signed SSL certificates, SSH keys,\n\u003e StackStorm access and DB/MQ passwords!\n\n2) Pull 3rd party Helm dependencies:\n```\nhelm dependency update\n```\n\n3) Install the chart\n```\nhelm install .\n```\n\n4) Upgrade\nOnce you make any changes to values, upgrade the cluster:\n```\nhelm upgrade \u003crelease-name\u003e .\n```\n\n## Configuration\n\nThe default configuration values for this chart are described in `values.yaml`.\n\n## Ingress\n\nIngress is worth considering if you want to expose multiple services under the same IP address, and\nthese services all use the same L7 protocol (typically HTTP). You only pay for one load balancer if\nyou are using native cloud integration, and because Ingress is \"smart\", you can get a lot of\nfeatures out of the box (like SSL, Auth, Routing, etc.). See the ingress section in `values.yaml`\nfor configuration details.\n\nYou will first need to deploy an ingress controller of your preference. See\nhttps://kubernetes.io/docs/concepts/services-networking/ingress-controllers/#additional-controllers\nfor more information.\n\n## Components\n\nThe Community FOSS Dockerfiles used to generate the docker images for each st2 component are available at\n[st2-dockerfiles](https://github.com/stackstorm/st2-dockerfiles).\n\n### st2client\nA helper container to switch into and run st2 CLI commands against the deployed StackStorm cluster.\nAll resources like credentials, configs, RBAC, packs, keys and secrets are shared with this container.\n```\n# obtain st2client pod name\nST2CLIENT=$(kubectl get pod -l app.kubernetes.io/name=st2client -o jsonpath=\"{.items[0].metadata.name}\")\n\n# run a single st2 client command\nkubectl exec -it ${ST2CLIENT} -- st2 --version\n\n# switch into a container shell and use st2 CLI\nkubectl exec -it ${ST2CLIENT} /bin/bash\n```\n\n### [st2web](https://docs.stackstorm.com/latest/reference/ha.html#nginx-and-load-balancing)\nst2web is a StackStorm Web UI admin dashboard. By default, st2web K8s config includes a Pod Deployment and a Service.\n`2` replicas (configurable) of st2web serve the web app and proxy requests to st2auth, st2api, st2stream.\nBy default, st2web uses HTTP instead of HTTPS. We recommend you rely on `LoadBalancer` or `Ingress` to add HTTPS layer on top of it.\n\u003e **Note!** By default, st2web is a NodePort Service and is not exposed to the public net.\n  If your Kubernetes cluster setup supports the LoadBalancer service type, you can edit the corresponding helm values to configure st2web as a LoadBalancer service in order to expose it and the services it proxies to the public net.\n\n### [st2auth](https://docs.stackstorm.com/reference/ha.html#st2auth)\nAll authentication is managed by `st2auth` service.\nK8s configuration includes a Pod Deployment backed by `2` replicas by default and Service of type ClusterIP listening on port `9100`.\nMultiple st2auth processes can be behind a load balancer in an active-active configuration and you can increase number of replicas per your discretion.\n\n### [st2api](https://docs.stackstorm.com/reference/ha.html#st2api)\nService hosts the REST API endpoints that serve requests from WebUI, CLI, ChatOps and other st2 components.\nK8s configuration consists of Pod Deployment with `2` default replicas for HA and ClusterIP Service accepting HTTP requests on port `9101`.\nBeing one of the most important StackStorm services with a lot of logic involved,\nwe recommend you increase the number of replicas if you expect increased load.\n\n### [st2stream](https://docs.stackstorm.com/reference/ha.html#st2stream)\nStackStorm st2stream - exposes a server-sent event stream, used by the clients like WebUI and ChatOps to receive updates from the st2stream server.\nSimilar to st2auth and st2api, st2stream K8s configuration includes Pod Deployment with `2` replicas for HA (can be increased in `values.yaml`)\nand ClusterIP Service listening on port `9102`.\n\n### [st2rulesengine](https://docs.stackstorm.com/reference/ha.html#st2rulesengine)\nst2rulesengine evaluates rules when it sees new triggers and decides if new action execution should be requested.\nK8s config includes Pod Deployment with `2` (configurable) replicas by default for HA.\n\n### [st2timersengine](https://docs.stackstorm.com/reference/ha.html#st2timersengine)\nst2timersengine is responsible for scheduling all user specified [timers](https://docs.stackstorm.com/rules.html#timers) aka st2 cron.\nOnly a single replica is created via K8s Deployment as timersengine can't work in active-active mode at the moment\n(multiple timers will produce duplicated events) and it relies on K8s failover/reschedule capabilities to address cases of process failure.\n\n### [st2workflowengine](https://docs.stackstorm.com/reference/ha.html#st2workflowengine)\nst2workflowengine drives the execution of orquesta workflows and actually schedules actions to run by another component `st2actionrunner`.\nMultiple st2workflowengine processes can run in active-active mode and so minimum `2` K8s Deployment replicas are created by default.\nAll the workflow engine processes will share the load and pick up more work if one or more of the processes become available.\n\u003e **Note!**\n\u003e As Mistral is going to be deprecated and removed from StackStorm platform soon, Helm chart relies only on\n\u003e  [Orquesta st2workflowengine](https://docs.stackstorm.com/orchestra/index.html) as a new native workflow engine.\n\n### [st2scheduler](https://docs.stackstorm.com/reference/ha.html#st2scheduler)\n`st2scheduler` is responsible for handling ingress action execution requests.\n`2` replicas for K8s Deployment are configured by default to increase StackStorm scheduling throughput.\n\n### [st2notifier](https://docs.stackstorm.com/reference/ha.html#st2notifier)\nMultiple st2notifier processes can run in active-active mode, using connections to RabbitMQ and MongoDB and generating triggers based on\naction execution completion as well as doing action rescheduling.\nIn an HA deployment there must be a minimum of `2` replicas of st2notifier running, requiring a coordination backend,\nwhich in our case is `Redis`.\n\n### [st2sensorcontainer](https://docs.stackstorm.com/reference/ha.html#st2sensorcontainer)\nst2sensorcontainer manages StackStorm sensors: It starts, stops and restarts them as subprocesses.\nBy default, deployment is configured with `1` replica containing all the sensors.\n\nYou can increase the number of `st2sensorcontainer` pods by increasing the number of deployments.\nThe replicas count is still only `1` per deployment, but the sensors are distributed between the deployments using\n[Sensor Hash Range Partitioning](https://docs.stackstorm.com/reference/sensor_partitioning.html#hash).\nThe hash ranges are calculated automatically based on the number of deployments.\n\nst2sensorcontainer also supports a more Docker-friendly single-sensor-per-container mode as a way of\n[Sensor Partitioning](https://docs.stackstorm.com/latest/reference/sensor_partitioning.html). This\ndistributes the computing load between many pods and relies on K8s failover/reschedule mechanisms,\ninstead of running everything on a single instance of st2sensorcontainer. The sensor(s) must be\ndeployed as part of the custom packs image.\n\nAs an example, override the default Helm values as follows:\n\n```\nst2:\n  packs:\n    sensors:\n      - name: github\n        ref: githubwebhook.GitHubWebhookSensor\n      - name: circleci\n        ref: circle_ci.CircleCIWebhookSensor\n```\n\n### [st2actionrunner](https://docs.stackstorm.com/reference/ha.html#st2actionrunner)\nStackstorm workers that actually execute actions.\n`5` replicas for K8s Deployment are configured by default to increase StackStorm ability to execute actions without excessive queuing.\nRelies on `redis` for coordination. This is likely the first thing to lift if you have a lot of actions\nto execute per time period in your StackStorm cluster.\n\n### [st2garbagecollector](https://docs.stackstorm.com/reference/ha.html#st2garbagecollector)\nService that cleans up old executions and other operations data based on setup configurations.\nHaving `1` st2garbagecollector replica for K8s Deployment is enough, considering its periodic execution nature.\nBy default this process does nothing and needs to be configured in st2.conf settings (via `values.yaml`).\nPurging stale data can significantly improve cluster abilities to perform faster and so it's recommended to configure st2garbagecollector in production.\n\n### [st2chatops](https://docs.stackstorm.com/chatops/index.html)\nStackStorm ChatOps service, based on hubot engine, custom stackstorm integration module and preinstalled list of chat adapters.\nDue to Hubot limitation, st2chatops doesn't provide mechanisms to guarantee high availability and so only single `1` node of st2chatops is deployed.\nThis service is disabled by default. Please refer to Helm `values.yaml` about how to enable and configure st2chatops with ENV vars for your preferred chat service.\n\n### [MongoDB ReplicaSet](https://github.com/bitnami/charts/tree/master/bitnami/mongodb)\nStackStorm works with MongoDB as a database engine. External Helm Chart is used to configure MongoDB [ReplicaSet](https://docs.mongodb.com/manual/tutorial/deploy-replica-set/).\nBy default `3` nodes (1 primary and 2 secondaries) of MongoDB are deployed via K8s StatefulSet.\nFor more advanced MongoDB configuration, refer to bitnami [mongodb](https://github.com/bitnami/charts/tree/master/bitnami/mongodb)\nHelm chart settings, which might be fine-tuned via `values.yaml`.\n\nThe deployment of MongoDB to the k8s cluster can be disabled by setting the mongodb-ha.enabled key in values.yaml to false.  *Note: Stackstorm relies heavily on connections to a MongoDB instance.  If the in-cluster deployment of MongoDB is disabled, a connection to an external instance of MongoDB must be configured.  The st2.config key in values.yaml provides a way to configure stackstorm.  See [Configure MongoDB](https://docs.stackstorm.com/install/config/config.html#configure-mongodb) for configuration details.*\n\n### [RabbitMQ HA Cluster](https://docs.stackstorm.com/latest/reference/ha.html#rabbitmq)\nRabbitMQ is a message bus StackStorm relies on for inter-process communication and load distribution.\nExternal Helm Chart is used to deploy [RabbitMQ cluster](https://www.rabbitmq.com/clustering.html) in Highly Available mode.\nBy default `3` nodes of RabbitMQ are deployed via K8s StatefulSet.\nFor more advanced RabbitMQ configuration, please refer to bitnami [rabbitmq](https://github.com/bitnami/charts/tree/master/bitnami/rabbitmq)\nHelm chart repository, - all settings could be overridden via `values.yaml`.\n\nThe deployment of RabbitMQ to the k8s cluster can be disabled by setting the rabbitmq-ha.enabled key in values.yaml to false.  *Note: Stackstorm relies heavily on connections to a RabbitMQ instance.  If the in-cluster deployment of RabbitMQ is disabled, a connection to an external instance of RabbitMQ must be configured.  The st2.config key in values.yaml provides a way to configure stackstorm.  See [Configure RabbitMQ](https://docs.stackstorm.com/install/config/config.html#configure-rabbitmq) for configuration details.*\n\n### [redis](https://docs.stackstorm.com/latest/reference/ha.html#zookeeper-redis)\nStackStorm employs redis sentinel as a distributed coordination backend, required for st2 cluster components to work properly in HA scenario.\n`3` node Redis cluster with Sentinel enabled is deployed via external bitnami Helm chart dependency [redis](https://github.com/bitnami/charts/tree/master/bitnami/redis).\nAs any other Helm dependency, it's possible to further configure it for specific scaling needs via `values.yaml`.\n\n## Install custom st2 packs in the cluster\nThere are two ways to install st2 packs in the k8s cluster.\n\n1. The `st2packs` method is the default. This method will work for practically all clusters, but `st2 pack install` does not work. The packs are injected via `st2packs` images instead.\n\n2. The other method defines shared/writable `volumes`. This method allows `st2 pack install` to work, but requires a persistent storage backend to be available in the cluster. This chart will not configure a storage backend for you.\n\nNOTE: In general, we recommend using only one of these methods. See the NOTE under Method 2 below about how both methods can be used together with care.\n\n### Method 1: st2packs images (the default)\nThe `st2packs` method is the default. `st2 pack install` does not work because this chart (by default) uses read-only `emptyDir` volumes for `/opt/stackstorm/{packs,virtualenvs}`.\nInstead, you need to bake the packs into a custom docker image, push it to a private or public docker registry and reference that image in Helm values.\nHelm chart will take it from there, sharing `/opt/stackstorm/{packs,virtualenvs}` via a sidecar container in pods which require access to the packs\n(the sidecar is the only place where the volumes are writable).\n\n#### Building st2packs image\nFor your convenience, we created a new `st2-pack-install \u003cpack1\u003e \u003cpack2\u003e \u003cpack3\u003e` utility and included it in a container that will help to install custom packs during the Docker build process without relying on live DB and MQ connection.\nPlease see https://github.com/StackStorm/st2packs-dockerfiles/ for instructions on how to build your custom `st2packs` image.\n\n#### How to provide custom pack configs\nUpdate the `st2.packs.configs` section of Helm values:\n\nFor example:\n```\n  configs:\n    email.yaml: |\n      ---\n      # example email pack config file\n\n    vault.yaml: |\n      ---\n      # example vault pack config file\n```\nDon't forget running Helm upgrade to apply new changes.\n\nNOTE: On `helm upgrade` any configs in `st2.packs.configs` will overwrite the contents of `st2.packs.volumes.configs` (optional part of Method 2, described below).\n\n#### Pull st2packs from a private Docker registry\nIf you need to pull your custom packs Docker image from a private repository, create a Kubernetes Docker registry secret and pass it to Helm values.\nSee [K8s documentation](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) for more info.\n```\n# Create a Docker registry secret called 'st2packs-auth'\nkubectl create secret docker-registry st2packs-auth --docker-server=\u003cyour-registry-server\u003e --docker-username=\u003cyour-name\u003e --docker-password=\u003cyour-password\u003e\n```\nOnce secret created, reference its name in helm value: `st2.packs.images[].pullSecret`.\n\n### Method 2: Shared Volumes\nThis method requires cluster-specific storage setup and configuration. As the storage volumes are both writable and shared, `st2 pack install` should work like it does for standalone StackStorm installations. The volumes get mounted at `/opt/stackstorm/{packs,virtualenvs}` in the containers that need read or write access to those directories. With this method, `/opt/stackstorm/configs` can also be mounted as a writable volume (in which case the contents of `st2.packs.configs` takes precedence on `helm upgrade`).\n\nNOTE: With care, `st2packs` images can be used with `volumes`. Just make sure to keep the `st2packs` images up-to-date with any changes made via `st2 pack install`.\nIf a pack is installed via an `st2packs` image and then it gets updated with `st2 pack install`, a subsequent `helm upgrade` will revert back to the version in the `st2packs` image.\n\n#### Configure the storage volumes\nEnable the `st2.packs.volumes` section of Helm values and add volume definitions for both `packs` and `virtualenvs`.\nEach of the volume definitions should be customized for your cluster and storage solution.\n\nFor example, to use persistentVolumeClaims:\n```\n  volumes:\n    enabled: true\n    packs:\n      persistentVolumeClaim:\n        claimName: pvc-st2-packs\n    virtualenvs:\n      persistentVolumeClaim:\n        claimName: pvc-st2-virtualenvs\n```\n\nOr, for example, to use NFS:\n```\n  volumes:\n    enabled: true\n    packs:\n      nfs:\n        server: nfs.example.com\n        path: /var/nfsshare/packs\n    virtualenvs:\n      nfs:\n        server: nfs.example.com\n        path: /var/nfsshare/virtualenvs\n```\n\nPlease consult the documentation for your cluster's storage solution to see how to add the storage backend to your cluster and how to define volumes that use your storage backend.\n\n#### How to provide custom pack configs\nYou may either use the `st2.packs.configs` section of Helm values (like Method 1, see above),\nor add another shared writable volume similar to `packs` and `virtualenvs`. This volume gets mounted\nto `/opt/stackstorm/configs` instead of the `st2.packs.config` values.\n\nNOTE: If you define a configs volume and specify `st2.packs.configs`, anything in `st2.packs.configs` takes precdence during `helm upgrade`, overwriting config files already in the volume.\n\nFor example, to use persistentVolumeClaims:\n```\n  volumes:\n    enabled: true\n    ... # define packs and virtualenvs volumes as shown above\n    configs:\n      persistentVolumeClaim:\n        claimName: pvc-st2-pack-configs\n```\n\nOr, for example, to use NFS:\n```\n  volumes:\n    enabled: true\n    ... # define packs and virtualenvs volumes as shown above\n    configs:\n      nfs:\n        server: nfs.example.com\n        path: /var/nfsshare/configs\n```\n\n#### Caveat: Mounting and copying packs\nIf you use something like NFS where you can mount the shares outside of the StackStorm pods, there are a couple of things to keep in mind.\n\nThough you could manually copy packs into the `packs` shared volume, be aware that StackStorm does not automatically register any changed content.\nSo, if you manually copy a pack into the `packs` shared volume, then you also need to trigger updating the virtualenv and registering the content,\npossibly using APIs like:\n[packs/install](https://api.stackstorm.com/api/v1/packs/#/packs_controller.install.post), and\n[packs/register](https://api.stackstorm.com/api/v1/packs/#/packs_controller.register.post)\nYou will have to repeat the process each time the packs code is modified.\n\n#### Caveat: System packs\nAfter Helm installs, upgrades, or rolls back a StackStorm install, it runs an `st2-register-content` batch job.\nThis job will copy and register system packs. If you have made any changes (like disabling default aliases), those changes will be overwritten.\n\nNOTE: Upgrades will not remove files (such as a renamed or removed action) if they were removed in newer StackStorm versions.\nThis mirrors the how pack registration works. Make sure to review any upgrade notes and manually handle any removals.\n\n## Tips \u0026 Tricks\nGrab all logs for entire StackStorm cluster with dependent services in Helm release:\n```\nkubectl logs -l app.kubernetes.io/instance=\u003crelease-name\u003e\n```\n\nGrab all logs only for stackstorm backend services, excluding st2web and DB/MQ/redis:\n```\nkubectl logs -l app.kubernetes.io/instance=\u003crelease-name\u003e,app.kubernetes.io/component=backend\n```\n\n## Running jobs before/after install, upgrade, or rollback\nWARNING: The feature described in this section is an Advanced feature that new users should not need.\n\nIt may be convenient to run one or more `Job`(s) in your `stackstorm-ha` cluster to manage your release's life cycle.\nAs the [Helm docs]() explain:\n\n\u003e Helm provides a _hook_ mechanism to allow chart developers to intervene at certain points in a release's life cycle.\n\nThe `jobs.extra_hooks` feature in this chart simplifies creating `Jobs` that Helm will run in its hooks.\nThese jobs will use the same settings as any other job defined by this chart (eg image, annotations, pod placement).\nThe `st2.conf` files and packs volumes will be mounted in the Job and the `st2` cli will be configured.\nThis feature is primarily useful when you need to run a StackStorm workflow (with `st2 run ...`) after install,\nbefore/after upgrades, or before/after rollbacks.\n\nNOTE: The `jobs.extra_hooks` feature is very opinionated. If you need to to apply helm hooks to anything other than\n`Jobs`, or if these jobs do not meet your needs, then you will need to do so from a parent chart. For example, parent charts\nare much better suited to jobs that don't need access to the packs, configs, configmaps, and secrets that this chart provides.\nSee \"Extending this chart\" below.\n\nThese extra hooks jobs can be used for st2 installation-specific jobs like:\n\n- running a pre-upgrade st2 workflow that notifies on various channels that the upgrade is happening,\n- running post-upgrade smoke tests to ensure st2 can connect to vital services (vault, kubernetes, aws, etc),\n- running a pre-upgrade st2 workflow that pauses long-running workflows,\n- running a post-upgrade st2 workflow that resumes long-running workflows,\n- running one-time post-install configuration (such as generating dynamic secrets in the st2kv datastore),\n\nTo configure the `jobs.extra_hooks`, set `jobs.extra_hooks` in your values file.\nPlease refer to stackstorm-ha's default values.yaml file for examples.\n\n## Extending this chart\nIf you have any suggestions or ideas about how to extend this chart functionality,\nwe welcome you to collaborate in [Issues](https://github.com/stackstorm/stackstorm-k8s/issues)\nand contribute via [Pull Requests](https://github.com/stackstorm/stackstorm-k8s/pulls).\nHowever if you need something very custom and specific to your infra that doesn't fit official chart plans,\nwe strongly recommend you to create a parent Helm chart with custom K8s objects and referencing `stackstorm-ha` chart\nas a child dependency.\nThis approach allows not only extending sub-chart with custom objects and templates within the same deployment,\nbut also adds flexibility to include many sub-chart dependencies and pin versions as well as include all the sub-chart values in one single place.\nThis approach is infra-as-code friendly and more reproducible. See official Helm documentation about\n[Subcharts](https://helm.sh/docs/chart_template_guide/#subcharts-and-global-values) and [Dependencies](https://helm.sh/docs/developing_charts/#managing-dependencies-manually-via-the-charts-directory).\n\n## Releasing information\nIn order to create a release, the steps are as follows:\n1. Create a pull request by updating [CHANGELOG.md](./CHANGELOG.md) by replacing the \"In Development\" heading with the new version, and [Chart.yaml](./Chart.yaml) by replacing the `version` value.\n2. Once the pull request is merged, create and push the matching tag (for example, if you are creating release `v1.0.0`, then the tag should also be `v1.0.0`).\n3. After the tag is pushed, create the corresponding [release](https://github.com/StackStorm/stackstorm-k8s/releases).\n4. After the release is created, switch to the `gh-pages` branch, and generate the updated [Helm index](https://helm.sh/docs/helm/helm_repo_index/), [package](https://helm.sh/docs/helm/helm_package/) and [provenance](https://helm.sh/docs/topics/provenance/).\n5. After committing and pushing the changes in the previous step, verify that the new release is present on [ArtifactHub](https://artifacthub.io/packages/helm/stackstorm/stackstorm-ha).\n","funding_links":["https://funding.communitybridge.org/projects/stackstorm"],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstackstorm%2Fstackstorm-k8s","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstackstorm%2Fstackstorm-k8s","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstackstorm%2Fstackstorm-k8s/lists"}