Manifests

Manifests let you group related kapps together:

stacks

They make it easy to set defaults for kapps and to select related kapps to work with.

The above example shows 4 manifests which could be used to define a stack. You could install kapps but exclude all the monitoring ones with -x 'monitoring:*'. Or you could simply comment out the monitoring manifest from the list of manifests defined in the stack if you didn’t need them.

Configuration

Manifests can contain the following settings:

  • defaults - set default values for kapps for the whole manifest (see below)
  • options - currently the only supported option is sequential which informs Sugarkube that each kapp depends on the previous one. See dependencies for more.
  • kapps - the configs for the kapps in the manifest. You can override any setting defined in the kapp. The only required setting is sources which is used when building a workspace to download kapps.

Defaults

You can define default kapp values at the manifest level. So if you have some variables used by a lot of kapps in the manifest, you could set their value once, e.g.:

defaults:
  vars:
    tiller_namespace: "{{ .stack.cluster }}"

Example

An example manifest is as below:

options:
  sequential: true      # kapps in this manifest must be installed in order
  
defaults:
  vars: 
    size: medium
  
kapps:
  - id: demo-kapp       # Manifest-unique identifier
    state: present
    - uri: git@github.com:sugarkube/kapps.git//incubator/demo-kapp#1.2.3
    - uri: git@github.com:sugarkube/kapps.git//incubator/common-makefiles#1.0.0
  vars:
    size: small
    hostname: "{{ .stack.cluster }}.localhost"

You can see example manifest files in our sample project.