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, Commander 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, Commander applies the combined values; for a manual deployment, Commander populates the wizard with the combined values.
- created outside of Commander (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.
Configuration menu > Policies
Commander Role of Superuser and Enterprise Admin
Administrator Access Rights
To configure a Default Ownership policy:
- On the Configuration page, click Add.
- On the Choose a Policy page, select Default Ownership from the list of policies, then click Next.
- On the Policy Name/Description page, enter a name for the policy, and an optional description, then click Next.
- On the Choose a Target page, from the Target View Type list, choose Infrastructure or Applications.
- If a service is deployed into a location where multiple policies target the Infrastructure view and the Applications view, the policy targeting the Infrastructure view takes precedence.
- You can only select managed Kubernetes clusters as targets for an ownership policy through the Applications tree.
- To select the target for the policy, navigate to the appropriate infrastructure elements in the Infrastructure or Applications tree on the right, then click Next.
Caution: Selecting the root Infrastructure or Applications object as the policy target will configure a system-wide policy. This means that the policy will be applied to all current and future Commander 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 Infrastructure or Applications as a target, you should select specific managed systems , infrastructure elements within managed systems, or Kubernetes clusters.
- On the Configure the Policy page, select Enable Policy for the policy to come into effect immediately after you finish configuring it.
- 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.
- If you want to set up a new command workflow at this point, click Add Workflow.
- A command 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, a workflow won't be run on the clusters' namespaces or their child resources. If a policy targets both non-Kubernetes resources and Kubernetes clusters, the workflow will only be run on the non-Kubernetes resources.
- 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 Commander 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.
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.