Barclamp proposal schema

Adam Spiers edited this page Aug 26, 2016 · 4 revisions

FIXME: this page is probably out of date!

Start Stop Field Comments
1 * id Name of instance or proposal. Must be unique in both the instance and proposal space
1 * description String of text that describe the instance of the barclamps
1 * attributes A map of values specific to the barclamp - usually a map named after the barclamp is the first container, but isn't required.
1 * deployment A map of one field named for the barclamp. This will contain barclamp specific configuartion for this instance.
1 * ===barclamp name === A map of 4 elements for barclamp specific configuration
1 * elements A map of roles that have lists of nodes for each role
1 * element_order A list of lists that represent the order in which elements should be deployed. See below.
1 * crowbar-revision The stored revision of this proposal/role. It is incremented by the system on saves.
1 * crowbar-commiting Flag the system uses to indicate if the proposal is being committed.
1 * crowbar-queued Flag the system uses to indicated that the proposal is queued.
2 * crowbar-status The status result of the last commit of this proposal (failed or success)
2 * crowbar-failed The message that accompanies a failed status
1 * config A map of values used to control how and when the barclamp instance is called
1 * environment A unique identifier for this barclamp instance. This is used in recipes to filter nodes and roles for this instance.
1 * mode Mode of operation of the barclamp. Currently, only full is supported.
1 * transitions A boolean value indicating that this barclamp has a transition function that should be called.
1 * transition_list A list of strings indicating the states that this barclamp instance wants to be notified about.

When applying the configuration to the environment, the barclamp framework first walks the element_order list and adds each role to each node that is associated with that role. This is done in strict order, so that the role that is listed first will be executed first for a given node, and the role that is listed last for a given node will be executed last.

Once the run lists are updated, the barclamp framework iterates through the element_order sub-lists, invoking chef-client in parallel on every node that is associated with at least one of the roles in that sub-list. Note that this may mean that chef-client is invoked multiple times on a single node. It would, in fact, be invoked once per sub-list for a node that is associated with at least one role in every sublist.


Current schema (Version 2):

{ "type": "map", "required": true, "mapping": { "id": { "type": "str", "required": true, "pattern": "/^bc-nova-|^bc-template-nova$/" }, "description": { "type": "str", "required": true }, "attributes": {

##### BARCLAMP SPECIFIC INFORMATION HERE #####

}, "deployment": { "type": "map", "required": true, "mapping": { "nova": { "type": "map", "required": true, "mapping": { "crowbar-revision": { "type": "int", "required": true }, "crowbar-committing": { "type": "bool" }, "crowbar-queued": { "type": "bool" }, "element_states": { "type": "map", "mapping": { = : { "type": "seq", "required": true, "sequence": [ { "type": "str" } ] } } }, "elements": { "type": "map", "required": true, "mapping": { = : { "type": "seq", "required": true, "sequence": [ { "type": "str" } ] } } }, "element_order": { "type": "seq", "required": true, "sequence": [ { "type": "seq", "sequence": [ { "type": "str" } ] } ] }, "config": { "type": "map", "required": true, "mapping": { "environment": { "type": "str", "required": true }, "mode": { "type": "str", "required": true }, "transitions": { "type": "bool", "required": true }, "transition_list": { "type": "seq", "required": true, "sequence": [ { "type": "str" } ] } } } } } } } } }