Order of Precedence for Metadata and Service Settings

The service catalog, request forms, workflows, deployment destinations, policy and global configuration all work together to provide a highly flexible and customizable system for automating the service request process. This topic explains the order of precedence for the assignment of service settings.

Policies and metadata

The Default Attributes policy (which automatically assigns expiry information as well as group membership) and the Default Ownership policy ensure that all new VMs are assigned metadata at creation time, no matter how they're created. These policies work in two ways:

  • During a Commander deployment (automated or manual), if Commander finds a policy targeting the selected destination, it calculates the policy actions and combines them with the other metadata (inherited from the source template and supplied on the request form). During automated deployment, Commander applies the combined values. During manual deployment, Commander populates the wizard with the combined values.
  • The policy is triggered when a new service is created directly in the cloud account — that is, outside of Commander.

If VMs are migrated into an area of your virtual infrastructure targeted by policy, metadata isn't automatically assigned. These policies affect VMs only at creation time.

If a VM is deployed into a location where multiple policies target the Infrastructure view or the Applications view, the policy targeting the Infrastructure view takes precedence.

It's best practice to set metadata (ownership, expiry information, and custom attribute values) either through policy or through a completion workflow, not both. The metadata values that are applied last are those that take effect. For more information, see Built-in Commander workflow steps.

General order of precedence for assigning service request settings

This section covers general assignment of settings for new requested services, such as:

  • ownership and organization assignment
  • expiry information
  • custom attribute values
  • deployment destination

The order of precedence for assignment of service settings is as follows (the first item in the list takes precedence):

  1. Settings specified in a completion workflow (not applicable to storage selection).
  2. Settings specified by an administrator during manual deployment.
  3. Deployment parameters specified by an approval workflow script (see Specify Deployment Parameters for Services), or by an approver through the approval comments (see Approve or Reject Service Requests).
  4. Information specified by a user on the request form.
  5. Settings specified in the service catalog entry.
  6. Settings specified in the Default Attributes policy (for expiry information and service groups only) .

    If a VM is deployed to a location where multiple policies target the Infrastructure view or the Applications view, the policy targeting the Infrastructure view takes precedence.

  7. Settings specified on the source template or image.

Order of precedence for assigning groups to requested services

The order of precedence for setting service groups is as follows (the first item in the list takes precedence):

  1. Groups set with the Set Groups completion workflow step.
  2. Groups specified by an administrator during manual deployment.
  3. Groups set in the service catalog blueprint.
  4. Groups set by the Default Attributes policy.

    If a service is deployed into a location where multiple policies target the Infrastructure view or the Applications view, the policy targeting the Infrastructure view takes precedence.

  5. Groups set for the source template or image.
  6. If none of the above causes a group to be applied, the default group is applied (except for power schedule groups).

    Expiry groups and maintenance groups apply to all service types (VMs, virtual services, application stacks, auto scaling groups, databases and load balancers). Maintenance groups also apply to managed systems. Other group types apply only to VMs.

Order of precedence for assigning networks to requested VMs

Once the destination is selected, the network for a requested VM is chosen according to the following order of precedence (the first item in the list takes precedence):

  1. Network specified in a completion workflow.
  2. Network specified by an administrator during manual deployment.
  3. Value for the first occurrence of a $NETWORK$ deployment parameter specified by an approval workflow script (see Specify Deployment Parameters for Services), or by an approver through the approval comments (see Approve or reject service requests).
  4. Network matching the network zone specified by a user on the request form.
  5. Network matching the network zone specified in the service catalog blueprint.

Order of precedence for assigning storage locations for requested VMs

Once the destination is selected, the storage location for a requested VM is chosen according to the following order of precedence (the first item in the list takes precedence):

  1. Datastore specified by an administrator during manual deployment.
  2. Value of the first occurrence of the $DATASTORE$ deployment parameter specified by an approval workflow script (see Specify Deployment Parameters for Services), or by an approver through the approval comments (see Approve or reject service requests).
  3. Storage tier specified by the requester on the request form.
  4. Storage tier specified in the service catalog blueprint.

Order of precedence for assigning disk formats for requested services

The disk format for new requested services is chosen according to the following order of precedence (the first item in the list takes precedence):

  1. Disk format specified in the provisioning destination.
  2. Disk format of the source template or image.

If you want to use the source template or source image settings, select Same format as source on the Disk Format page of the Automated Deployment Placement wizard.

Order of precedence for assigning names to requested services

The name for a requested service is chosen according to the following order of precedence (the first item in the list takes precedence):

  1. Name specified during manual deployment (text replacement rules are not used in this case).
  2. Value of the first occurrence of the $VMNAME$ deployment parameter specified by an approval workflow script (see Specify Deployment Parameters for Services), or by an approver through the approval comments (see Approve or reject service requests).
  3. Name specified by a requester on the New Service Request form (text replacement rules aren't used in this case).
  4. Deployed Name specified in the service catalog entry.
  5. The naming convention specified in Global Provisioning Configuration.

Order of precedence for assigning key pairs to requested services

If multiple key pair assignments are valid for a requested instance, a key pair is assigned using the following order of precedence (the first item in the list takes precedence):

  1. The key pair selected by an administrator during manual deployment.
  2. The key pair selected by a user on the request form.
  3. The key pair configured on the service catalog blueprint.
  4. The key pair matching the credential assigned to the requester.
  5. The key pair matching the credential assigned to the requester's organization.
  6. The key pair configured on the target deployment destination.

For more information, see Enable Key Pair SSH Connections to Amazon EC2 VMs.

Request form visibility

The service portion of a new service request form is shown in the following order of precedence (the first item in the list takes precedence):

  1. Form assigned directly to a user
  2. Form assigned to the user's organization
  3. Form assigned to a user's directory services group
  4. Otherwise, the global form is displayed

The component portion of a new service request form is configured as part of the service catalog entry.

For change requests, a user can see all forms assigned to them, either directly or to their organization.

Deployment destination visibility

The deployment destination is chosen in the following order of precedence (the first item in the list takes precedence):

  1. Destination specified by an administrator during manual deployment.
  2. Value of the first occurrence of the $DESTINATION$ deployment parameter specified by an approval workflow (see Specify Deployment Parameters for Services), or by an approver through the approval comments (see Approve or reject service requests).
  3. Destination specified by a requester on the New Service Request form.
  4. Destination specified by a requester on the New Service Request form. For more information, see Service Request Form Elements.

    The Limit Selections option for the Destination form element also affects deployment destination visibility.

  5. Destination matching the network zone and storage tier specified in the service catalog entry

Direct assignment vs. membership in a group or organization

If a user is a member of a group or organization, the most specific assignment takes precedence, as follows:

  1. Destinations assigned directly to this user.
  2. Destinations assigned to an organization where the user is a direct member.
  3. Destinations assigned to a group where the user is a direct member.
  4. Destinations assigned to a parent group (that is, a parent group of a group where this user is a direct member).

This order ensures that you can control what destinations users will see. For example, if a destination is assigned to a parent group, but not to a child group, a member of the child group will only see that destination if the user has no more specific assignments (numbers 1 and 2 in the order of precedence).

Likewise, if a destination is assigned directly to an organization member and also to the organization, the destination assigned to the organization member is chosen.

Ownership inheritance and precedence

This section explains how ownership information is inherited, and the order of precedence for setting ownership information.

Ownership inheritance from source VM or template

A deployed VM doesn't inherit ownership from its source VM or template, with one exception: when a user shares a VM, there's an option for the deployed VM to keep the source VM's existing owners.

For example, if you want all VMs deployed from a database service component to have your database admin as the IT owner, it's easy to configure this. For each service component where you require this ownership model, set up a component-level completion workflow. On the Steps page of the wizard, add a Set Ownership step (in the Lifecycle Management category). On the Assigned Components page, assign the workflow to the appropriate component in your Service Catalog. For more information, see Create Completion Workflows.

What ownership type takes precedence

Commander uses the "most permissive" ownership model. This means that if a user belongs to a group or organization that owns a service, and the user is also an individual owner of a service, the higher level of ownership permissions is always used. For example, Jose is a member of the group Development, which is the primary owner of a particular VM, but Jose is also an "other" owner of the VM. In this case, Jose is treated as a primary owner for that VM.

Metadata inheritance for VM children of virtual services, auto scaling groups and application stacks

This section explains how ownership, expiry information and custom attribute values are inherited by the VM children of virtual services, auto scaling groups and application stacks. For brevity, in this section, the term "virtual service" is used to represent virtual services, auto scaling groups and application stacks.

New virtual service deployments

  • Ownership information isn't inherited by virtual service children during deployment. For example, if the primary owner set on the VM request form is different from the virtual service's primary owner, the primary owner from the request form is applied to the VM.
  • Expiry information: An expiry date set for a virtual service automatically applies to all of its children, overriding existing values. If required, you can apply a different expiry date to a child VM.
  • Custom attribute values: Because you would typically set different custom attribute values for a virtual service and its children, custom attribute values set for a virtual service are not inherited by its children.

VMs deployed or moved into existing virtual services

When a new VM is deployed into an existing virtual service, or when a VM is moved into an existing virtual service, the following rules apply:

  • Ownership: The VM inherits ownership information from the virtual service. Existing ownership information isn't overwritten: all virtual service owners are appended to the list of VM owners, and any existing Primary Owners and IT contacts on the VM are preserved.
  • Expiry information: The VM inherits expiry information from the virtual service.
  • Custom attribute values: The VM doesn't inherit custom attribute values from the virtual service.

New VMs launched by an Amazon EC2 Auto Scaling Group

New VMs launched by an Auto Scaling Group inherit metadata from the auto scaling group, including ownership, expiry information and group membership. The exception to this rule is custom attribute values.

Changes to existing VMs and virtual services

  • Ownership: If ownership is changed on an existing virtual service, the new ownership information is inherited by its child VMs, overriding any existing ownership.

    If a child VM's owner is removed, the virtual service ownership information isn't inherited by the VM. This allows you flexibility in assigning ownership of virtual service children. It also means that a virtual service can be visible to a Service Portal user when the child VMs are not visible, or vice-versa. Make sure that all VMs in a virtual service have the correct ownership information.

  • Expiry information: If you change expiry information for a virtual service, VM children inherit the new values.
  • Custom attribute values: If you change custom attribute values for an existing virtual service, VM children don't inherit the new values.

Cloned virtual services

When a virtual service is cloned in Commander, all metadata values are preserved for VM children.