Usage Guide

Resource Definitions

Resource definitions are declarative yaml files which describe the infrastructure and services to be deployed via Cloudbreak. There are two kinds of Resource Definitions:

Infrastructure

A Cloudbreak 'Stack' consisting of one or more servers deployed via Ambari.

Services

A combination of one or more Infrastructure components, usually with additional steps and controls to bind them together

Both types of resource definition share a common Yaml format, with the selection of included fields dictating the behavior.

Under a resource root defined in your Profile (profile:resources), the Orchestrator expects to find one or more folders named for the Service Definition contained within (e.g. hdp3), and each of those folders must contain a yaml file of the same name defining the service (e.g hdp3/hdp3.yaml)

The folder should also contain all the additional blueprints, scripts, etc. that the Definition calls for (e.g. hdp3/blueprint.json, hdp3/deploy.sh)

/resources
/resources/hdp3
/resources/hdp3/hdp3.yaml
/resources/hdp3/blueprint.json
/resources/hdp3/recipe.sh
/resources/hdp3/... etc.

Infrastructure Definition

asd

Service Definition

The Service Definition declares the controls and steps required to chain together one or more Infrastructure Definitions for a deployment.

Here is an example:

purge: false
priority: 1
seq:
- openport: [-1, 1, 65534, '10.20.30.40/32']
- openport: [tcp, 22, 22, '0.0.0.0/0']
- prepdeps: [hdp3, hdp3]
- prepspec: [hdp3, hdp3]
- deploy: [hdp3]
- wait: [hdp3, hdp3, event_type, BILLING_STARTED]
- writecache: [hdp3, public_ip, DPSPUBLICIP]

purge

Controls whether any existing components should be deleted during a deployment run

Relies on the Namespace in your Profile to select the correct set of components

priority

If this field is populated, the Orchestrator will attempt to deploy this definition

If multiple definitions are present, the Orchestrator will attemp to alpha sort the priority field to determine the desired sequence, so using 1,2,3,4,etc. is recommended

seq

The list of steps under seq will be executed in order written until the process completes or an error is encountered

The steps should be constructed such that the process can be run repeatedly without adverse effects

The list supports a limited number of primitive instructions as defined in the Orchestrator

Sequence Primitives

openport

[protocol, start port, end port, CIDR]

prepdeps

things

prepspec

other stuff

deploy

different things

wait

for the end

writecache

something useful