Environments

Define environments based on what distinguishes them within your estate, such as location, purpose, or underlying technology. Names like San Jose production, Building 45 training lab, or SF QA lab are typical.

How environments shape an order

Ordering begins with a group and an environment, and those two choices build the rest of the order form: which options a user can pick and which parameters they are asked for.

Administrators (and anyone with the group.manage_parameters permission) can attach parameters to a group or to an environment to shape that form. Adding an expiration date parameter to a group, for example, means everyone ordering in that group is asked for one.

See Order form customization for how the form is assembled.

One resource handler per environment

Each environment uses a single resource handler, and CMP contacts it whenever it creates or modifies a server in that environment. Selecting Power Off on a server, for instance, reaches that server’s vCenter or cloud account through its environment’s handler.

An environment can also be associated with a configuration manager, such as Ansible, Chef, or Puppet, to install operating systems, applications, and patches as servers are built.

Deploy to multiple clouds

Every technology has its own word for a deployment target: AWS and Azure call it a region, VMware a cluster, OpenStack a project. An environment is CMP’s abstraction over all of them, so a user sees the same order form wherever the workload lands.

Blueprints are not tied to a cloud, so a single blueprint can deploy to multiple environments. Enable a build item for each environment it should offer, on the blueprint’s Build tab, and the user chooses one at order time. See Build configuration.

To automatically choose the environment, write a plugin for the Environment Selection Orchestration trigger point.