Assigning Service Ownership with Default Ownership Policies

You can use a Default Ownership policy to automatically assign ownership to new services that are:

  • created through automated and manual deployments

    When there is a Default Ownership targeting the selected destination, vCommander applies the policy actions after they are combined with other metadata that may be inherited from a source template and supplied on the request form. For an automated deployment, vCommander applies the combined values; for a manual deployment, vCommander populates the wizard with the combined values.

  • created outside of vCommander (that is, created directly in the managed system or managed Kubernetes cluster)

A Default Ownership policy reduces the time required to set service ownership, and it ensures that services are always assigned to an owner who can manage them and the services are always visible to organization members.

Using a Default Ownership policy to automatically assign ownership to new services also allows you to track who's incurring service costs, and can be used to assign ownership to costs in public cloud billing data for the purposes of Cost Analytics.

You can also set ownership information through a completion workflow with a Set Ownership step. To ensure that the proper values are set, it's best to set metadata through policy or through a completion workflow, not both. The metadata values that are applied last are those that take effect. Note that you can't currently run workflows on any Kubernetes resources except for Kubernetes clusters.

Configuring Default Ownership policies

Access through:

Configuration menu > Policies

Available to:

vCommander Role of Superuser and Enterprise Admin

Administrator Access Rights

To configure a Default Ownership policy:

  1. On the Policies tab, click Add.
  2. On the Choose a Policy page, select Default Ownership from the list of policies, then click Next.
  3. On the Policy Name/Description page, enter a name for the policy, and an optional description, then click Next.
  4. On the Choose a Target page, from the Target View Type list, choose Operational or Deployed.

    Notes:

    • If a service is deployed into a location where multiple policies target the Operational view and the Deployed view, the policy targeting the Operational view takes precedence.
    • You can only select managed Kubernetes clusters as targets for an ownership policy through the Deployed tree.
  5. To select the target for the policy, navigate to the appropriate infrastructure elements in the Operational or Deployed tree on the right, then click Next.

    Caution: Selecting the root Operational or Deployed object as the policy target will configure a system-wide policy. This means that the policy will be applied to all current and future vCommander managed systems and Kubernetes clusters. If you don't want all managed systems and Kubernetes clusters to be automatically affected by the policy, instead of selecting Operational or Deployed as a target, you should select specific managed systems, infrastructure elements within managed systems, or Kubernetes clusters.

  6. On the Configure the Policy page, select Enable Policy for the policy to come into effect immediately after you finish configuring it.
  7. From the Take Action drop-down, select from the options:
    • Notify Only: An alert is created to notify you when the policy has triggered, but no action is taken for the service. See also Subscribing to Policy Alerts.
    • Run [Workflow]: The selected command workflow will be triggered when the policy is triggered.

      The available workflows are listed by target type. You must choose a workflow with a target type that matches the target of the policy, otherwise, the workflow will fail. For example, if the selected workflow's target type is "VM", the workflow will fail if the policy targets a database. A workflow with a target type of "Any Inventory Type" can be run on all service types.

      Notes:

      • If you want to set up a new command workflow at this point, click Add Workflow.
      • A workflow can't currently be run on Kubernetes namespaces or their child resources. Although you can select a workflow action for a target that includes managed Kubernetes clusters, no command workflow will be run on the clusters' namespaces or their child resources. If a policy targets both non-Kubernetes resources and Kubernetes clusters, the command workflow will only be run on the non-Kubernetes resources.
  8. In the Default Owners area, do the following:
    • Select an organization. This will make new services visible to the users in that organization.

      If you also assign ownership to one or more organization members, their organization is automatically selected. For a service to be visible to an organization member, the service must be assigned to the organization.

    • To assign users to the new service, in the Login/Email field, type a login ID or email address, then click Add. Each account you add must be a local user or group account set up within vCommander or a directory services user or group account.

      The first owner that is added to the policy is automatically assigned as a primary owner; you can change that assignment and the IT contact assignment as required.

  9. If you want to allow children of the targets to have their own instance of the policy, enable the For any children of the selected target(s)... checkbox.

    Enabling this option allows other instances of this policy to be applied to any infrastructure elements and services that are children of the parent infrastructure element you have selected (an override). See Walk-through: Configuring Organizations for an example of how this override can be useful.

    This option won't affect any managed Kubernetes clusters that are included with a target.

  10. On the Summary page, review the settings and click Finish.