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, PUBLICIP]
- replace: [demo, deploy.sh, PUBLICIP]

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, StartPort, EndPort, CIDR]

[tcp, udp, -1 (all)]; e.g. tcp

any port 1-65534; e.g 443

any port 1-65534; e.g 443

any IP / mask; e.g. 192.168.0.1/16

prepdeps

[DefinitionName, TargetName]

the Name Key of the Definition; e.g. hdp3

the Cluster Name to append to the Profile Namespace; e.g. my-hdp3-cluster

prepspec

[DefinitionName, TargetName]

the Name Key of the Definition; e.g. hdp3

the Cluster Name to append to the Profile Namespace; e.g. my-hdp3-cluster

deploy

[TargetName]

List of TargetNames to deploy in this Step; e.g. [hdp265-a, hdp265-b]

wait

[DefinitionName, TargetName, EventField, EventString]

the Name Key of the Definition; e.g. hdp3

the Cluster Name to append to the Profile Namespace; e.g. my-hdp3-cluster

the String of the Event Field to filter on; e.g. event_type

the String in the Event Field you are waiting for; e.g. BILLING_STARTED

writecache

[TargetName, Field, CacheKey]

The Name of the Cluster to retrieve the value from; e.g. my-hdp3-cluster

The name of the supported Field to retrieve from; e.g. public_ip

The Key to use when writing the value to Horton's Cache; e.g. DPSPUBLICIP

replace

`[DefinitionName, ResourceFile, CacheKey]

The Name Key of the Definition to modify; e.g. hdp3

The filename of the Resource within the Named Definition to modify; e.g. deploy.sh

The Key of the value to replace in the file, should match the string in the file to be replaced; e.g. PUBLICIP