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 updatecommand. 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 deletecommand. 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)
Actions enable several advanced usecases such as:
cluster_updateaction to install kops into that VPC.
You can see an example of actions in use in our sample project.