The configuration for a particular stack is built up by Sugarkube searching for and merging different YAML files. You may be aware that stacks are defined with the following settings:
name: dev provider: aws provisioner: kops account: dev # values don't need to be unique region: eu-west-1 profile: infra cluster: dev1
Each of these is used to build up the paths to files that Sugarkube will load and merge to create the final config for a given stack.
The search algorithm is as follows:
provider_vars_dirssetting (and in the order they’re defined in) and look for a directory with the name of the stack’s
.yaml, ignoring duplicates:
localprovider doesn’t do this)
.yamlextension) in that order. For each one found, enter it and repeat steps 2 and 3.
While simple, this algorithm is the key to much of Sugarkube’s flexibility for handling different configs, allowing large sections to be shared or overridden in different ways.
To see the exact paths Sugarkube is searching for run Sugarkube with logging enabled (
The above algorithm provides flexibility but does make it a bit less clear what the final config for a stack will be. To help with that Sugarkube has a
cluster vars command that will traverse the configured provider vars dirs merging configs. It will then print out the merged config so you can inspect it. It has various options for suppressing or selecting output to make it easier to see only what you’re interested in.