This is the documentation for the crowbar batch
subcommand.
crowbar batch
provides a quick way of creating,
updating, and applying Crowbar proposals. It can be used to:
accurately capture the configuration of an existing Crowbar environment.
drive Crowbar to build a complete new environment from scratch.
capture one SUSE OpenStack Cloud environment and then reproduce it on another set of hardware (provided hardware and network configuration match to an appropriate extent).
automatically update existing proposals.
As the name suggests, crowbar batch
is intended to be
run in “batch mode”, that is mostly unattended. It has two
modes of operation:
Exports a YAML file which describes existing proposals and how their parameters deviate from the default proposal values for that barclamp.
Imports a YAML file in the same format as above. Uses it to build new proposals if they do not yet exist. Updates the existing proposals so that their parameters match those given in the YAML file.
Here is an example YAML file. At the top-level, there is a proposals array, each entry of which is a hash representing a proposal:
proposals: - barclamp: provisioner # Proposal name defaults to 'default'. attributes: shell_prompt: USER@ALIAS:CWD SUFFIX - barclamp: database # Default attributes are good enough, so we just need to assign # nodes to roles: deployment: elements: database-server: - "@@controller1@@" - barclamp: rabbitmq deployment: elements: rabbitmq-server: - "@@controller1@@"
Note that the characters @
and `
are reserved indicators in YAML. They can appear anywhere in a string
except at the beginning. Therefore a string such as
@@controller1@@
needs to be quoted using double quotes.
Name of the barclamp for this proposal (required).
Name of this proposal (optional; default is
default
). In build
mode, if the
proposal does not already exist, it will be created.
An optional nested hash containing any attributes for this proposal which deviate from the defaults for the barclamp.
In export
mode, any attributes set to the default
values are excluded to keep the YAML as short and readable as
possible.
In build
mode, these attributes are deep-merged
with the current values for the proposal. If the proposal did not
already exist, batch build will create it first. The attributes
are merged with the default values for the barclamp's
proposal.
An optional array of paths to nested attributes which should be removed from the proposal.
Each path is a period-delimited sequence of attributes; for example
pacemaker.stonith.sbd.nodes
would remove all SBD
nodes from the proposal if it already exists. If a path segment
contains a period, it should be escaped with a backslash, for example
segment-one.segment\.two.segment_three
.
This removal occurs before the deep merge described above.
For example, think of a YAML file which includes a Pacemaker barclamp proposal
where the wipe_attributes
entry contains
pacemaker.stonith.sbd.nodes
. A batch build with this YAML file
ensures that only SBD nodes listed in the attributes sibling
hash
are used at the end of the run. In contrast, without the
wipe_attributes
entry, the given SBD nodes would
be appended to any SBD nodes already defined in the proposal.
A nested hash defining how and where this proposal should be deployed.
In build
mode, this hash is deep-merged in the
same way as the attributes hash, except that the array of elements
for each Chef role is reset to the empty list before the deep
merge. This behavior may change in the future.
A string like @@node@@
(where
node is a node alias) will be substituted for
the name of that node, no matter where the string appears in the YAML file.
For example, if controller1
is
a Crowbar alias for node
d52-54-02-77-77-02.mycloud.com
, then
@@controller1@@
will be substituted for that host
name. This allows YAML files to be reused across environments.
In addition to the standard options available to every
crowbar
subcommand (run crowbar batch
--help
for a full list), there are some extra options
specifically for crowbar batch
:
Only include the barclamp / proposals given.
This option can be repeated multiple times. The inclusion value can
either be the name of a barclamp (for example,
pacemaker
) or a specifically named proposal within
the barclamp (for example,
pacemaker.network_cluster
).
If it is specified, then only the barclamp / proposals specified are included in the build or export operation, and all others are ignored.
This option can be repeated multiple times. The exclusion value is the
same format as for --include
. The barclamps /
proposals specified are excluded from the build or export operation.
Change the timeout for Crowbar API calls.
As Chef's run lists grow, some of the later OpenStack barclamp proposals (for example Nova, Horizon, or Heat) can take over 5 or even 10 minutes to apply. Therefore you may need to increase this timeout to 900 seconds in some circumstances.