Actions

Actions provide a way for kapps to callback to Sugarkube to manipulate its state or to make it do things. Supported actions are:

  • cluster_update - instructs Sugarkube to update a cluster, similar to invoking the cluster update command. This allows you to create kapps that run before your cluster is created, e.g. to prepare the environment by creating hosted zones, a S3 state bucket, etc. and then calling back to Sugarkube to make it actually create the cluster at that point.
  • cluster_delete - instructs Sugarkube to delete a cluster, similar to invoking the cluster delete command. This allows you to make Sugarkube delete the cluster but then continue to delete infrastructure (such as hosted zones, S3 state buckets) that were used by the cluster.
  • add_provider_vars_files - adds extra file paths to the list of paths that will be merged together by the provider. This allows you to write kapps that dynamically modify e.g. the kops cluster config. Read below for more on this
  • none - don’t perform any action. This can be used when actions have been defined in a shared manifest, and you want to disable them for a single stack.

Actions are defined to run at different points of a kapp’s lifecycle:

  • pre_install_actions - run before the kapp is installed (only if it’s selected for installation)
  • post_install_actions - run after the kapp is installed (only if it’s selected for installation)
  • pre_delete_actions - run before the kapp is deleted (only if it’s selected for deletion)
  • post_delete_actions - run after the kapp is deleted (only if it’s selected for deletion)

Uses

Actions enable several advanced usecases such as:

  • Creating a private VPC to install kops into, then triggering a cluster_update action to install kops into that VPC.
  • Installing an OIDC provider (such as Keycloak) into the cluster, templating a new provider YAML file and adding it to the list of provider vars files. Then triggering a cluster update to reconfigure the cluster to use OIDC authentication instead of the default method.
  • Specifying exactly at before or after which kapp a cluster should be created, updated or deleted when installing or deleting kapps.

You can see an example of actions in use in our sample project.