Triggering Pre-defined Actions

ESC introduces a new REST API to trigger the existing (pre-defined) actions defined through the Dynamic Mapping API, when required. For more information on the Metrics and Actions APIs, see Metrics and Actions.

A sample predefined action is as follows:

<actions>
    <action>
        <name>SaidDoIt</name>
        <userlabel>My Friendly Action</userlabel>
        <type>SCRIPT</type>
        <metaData>
            <type>script</type>
            <properties>
                <property>
                    <name>script_filename</name>
                    <value>/opt/cisco/esc/esc-scripts/do_somethin.py</value>
                </property>
                <property>
                    <name>arg1</name>
                    <value>some_val</value>
                </property>
                <property>
                    <name>notification</name>
                    <value>true</value>
                </property>
            </properties>
        </metaData>
    </action>
</actions>

Note	A script file located on a remote server is also supported. You must provide the details in the <value> tag, for example, <value>http://myremoteserverIP:80/file_store/do_somethin.py</value>

The pre-defined action mentioned above is triggered using the trigger API.

Execute the following HTTP or HTTPS POST operation:

POST http://<IP_ADDRESS>:8080/ESCManager/v0/trigger/action/

POST https://<IP_ADDRESS>:8443/ESCManager/v0/trigger/action/

The following payload shows the actions triggered by the API, and the response received:

<triggerTarget>
  <action>SaidDoIt</action>
  <properties>
   <property>
     <name>arg1</name>
     <value>real_value</value>
   </property>
  </properties>
</triggerTarget>

<triggerResponse>
    <handle>c11be5b6-f0cc-47ff-97b4-a73cce3363a5</handle>
    <message>Action : 'SAIDDOIT' triggered</message>
</triggerResponse>

ESC accepts the request, and returns a response payload and status code.

An http status code of 200 indicates that the action triggered exists, and is triggered successfully. An http status codes of 400 or 404 indicate that the action to be triggered is not found.

You can determine the status using the custom script notifications sent to NB at various lifecycle stages.

ESC sends the MANUAL_TRIGGERED_ACTION_UPDATE callback event to NB with a status message that describes the success or failure of the action execution.

The notification is as follows:

<esc_event xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <event_type>MANUAL_TRIGGERED_ACTION_UPDATE</event_type>
    <properties>
        <property>
            <name>handle</name>
            <value>c11be5b6-f0cc-47ff-97b4-a73cce3363a5</value>
        </property>
        <property>
            <name>message</name>
            <value>Action execution success</value>
        </property>
        <property>
            <name>exit_code</name>
            <value>0</value>
        </property>
        <property>
            <name>action_name</name>
            <value>SAIDDOIT</value>
        </property>
    </properties>
</esc_event>

Note	The script_filename property cannot be overwritten by the trigger API request. The trigger API must not contain any additional properties that do not exist in the predefined action.

The new API allows to overrides some of the special properties (of the actions) listed below:

• Notification—Set this if your script generates progress notifications at run time. The default value is false. This value can be set to true in the action or trigger payload.

• wait_max_timeout—Wait for the script to complete the execution before terminating. The default wait timeout is 900 seconds.

Note

The trigger API supports only script type actions. Ensure that the script action located on the ESC VM is copied to the same path on both the Master and Backup HA instances. For more information, see the High Availability chapter in the Cisco Elastic Services Controller Install and Upgrade Guide. The script execution terminates if there is a failover, shutdown, or reboot of the ESC services.

Lifecycle Stage (LCS) Policy Conditions Defined at Different Stages

The tables below shows all policy conditions defined in the data model.

Intra Group Affinity Policy

The VNFs within the same VM group can either be deployed on the same host, or into the same availability zone.

Example for Intra Group Affinity Policy:

<vm_group>
     <name>affinity-test-gp</name>
     <placement>
	<type>affinity</type>
	<enforcement>strict</enforcement>
     </placement>
...

In ESC Release 2.0 and later, the type zone-host is used to deploy VNFs in the same host, or into the same availability zone.

Example for host placement:

<vm_group>
     <name>zone-host-test-gp1</name>
     <placement>
	<type>zone_host</type>
	<enforcement>strict</enforcement>
	<host>my-ucs-4</host>
     </placement>
...

Example for zone placement:

<vm_group>
     <name>zone-host-test-gp2</name>
     <placement>
	<type>zone_host</type>
	<enforcement>strict</enforcement>        
        <zone>dt-zone</zone>
     </placement>
...

Intra Group Anti-Affinity Policy

The VNFs within the same VM group are explicitly deployed on different hosts. For example, back-up VNFs.

Example for Intra Group anti-affinity Policy:

<vm_group>
        <name>anti-affinity-test-gp</name>
        <placement>
            <type>anti_affinity</type>
            <enforcement>strict</enforcement>
        </placement>
...

Inter Group Affinity Policy

The VNFs in the same deployment but different VM groups can be explicitly deployed in the same host. For example VNF bundles. Multiple VM groups can follow this policy by adding the vm_group_ref tag and providing the VM group name as the value.

Note	You can use one or more vm_group_ref tag, type tag and enforcement tag under the placement tag. The host or zone cannot be specified.

Example for Inter Group Affinity Policy:

 
<deployments>
            <deployment>
            <name>intergroup-affinity-dep</name>
             <policies>
              <placement>
                <target_vm_group_ref>affinity-test-gp1</target_vm_group_ref>
                <type>affinity</type>
                <vm_group_ref>affinity-test-gp2</vm_group_ref>
                <enforcement>strict</enforcement>
               </placement>
          </policies>
…

Inter Group Anti-Affinity Policy

The VNFs in the same deployment but different VM Groups can be explicitly deployed in different hosts. For example back-up VNFs or High-availability VNFs. Multiple VM groups can follow this policy by adding the vm_group_ref tag, and providing the VM group name as the value.

Note

You can only use one <target_vm_group_ref> tag, type tag and enforcement tag under the placement tag. The host or zone cannot be specified. You can use multiple <vm_group_ref> tags, however the anti-affinity policy only applies between each <vm_group_ref> and their <target_vm_group_ref>, which means that 2 or more <vm_group_ref> can be deployed on the same host, as long as each of them are deployed on a different host from their <target_vm_group_ref> that is acceptable.

Example for Inter Group anti-affinity Policy:

<deployments>
           <deployment>
            <name>intergroup-anti_affinity-dep</name>
             <policies>
              <placement>
                  <target_vm_group_ref>affinity-test-gp1</target_vm_group_ref>
                  <type>anti_affinity</type>
                  <vm_group_ref>affinity-test-gp2</vm_group_ref>
                  <enforcement>strict</enforcement>
               </placement>
          </policies>
…

In a multiple VIM deployment, the VM groups of a placement policy must belong to the same VIM. That is, the VIM connector must be the same for the VM groups (specified in the vim_id attribute in the locator tag of the VM group). ESC rejects a deployment if the affinity and anti-affinity policies between VM groups are on different VIMs. For more details on deploying VMs on multiple deployments, see Deploying VNFs on Multiple OpenStack VIMs.

A placement group tag is added under policies. Each <placement_group> contains the following:

• name—name unique per deployment.

• type—affinity or anti_affinity

• enforcement—strict

• vm_group—the content of each vm_group must be a vm group name listed under the same deployment.

The placement group tag is placed within the placement policy. The placement policy describes the relationship between the target vm group and the vm group members. The placement_group policy describes mutual relationship among all vm group members. The placement group policy is not applicable for target vm group.

The datamodel is as follows:

<policies>
	<placement_group>
		<name>placement-affinity-1</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g1</vm_group>
		<vm_group>t1g2</vm_group>
		<vm_group>t1g7</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-affinity-2</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g3</vm_group>
		<vm_group>t1g4</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-affinity-3</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g5</vm_group>
		<vm_group>t1g6</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-anti-affinity-1</name>
		<type>anti_affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g1</vm_group>
		<vm_group>t1g3</vm_group>
		<vm_group>t1g5</vm_group>
	</placement_group>
</policies>

Note

In the new placement group tag under policies, the <target_vm_group_ref> and <vm_group_ref> are replaced with <vm_group>. The ref based affinity and antiaffinity tags are deprecated. The placement group policy is applicable for inter group affinity and anti-affinity policies only. You cannot use both placement and placement group tags together in the inter group affinity and anti-affinity policies. The placement group name tag must be unique for each placement group policy.

Inter Deployment Anti-Affinity Policy

Inter Deployment anti-affinity rules define relationships between different deployments with respect to the host placement. Anti-affinity between deployments is defined such that any VM from one deployment is not co-located on the same host as any other VM from the other deployment.

Note	Inter Deployment anti-affinity is supported on OpenStack only. Inter Deployment anti-affinity does not work with host-placement (affinity or anti-affinity) as the latter takes precedence over inter deployment anti-affinity rules.

In the ESC datamodel, inter deployment anti-affinity is defined using anti-affinity groups. All member deployments of an anti-affinity group have an anti-affinity relationship between them. For example, in an anti-affinity group called default-anti with 3 deployments dep-1, dep-2 and dep-3, dep-1 is anti-affinity to dep-2 and dep-3 deployments, dep-2 is anti-affinity to dep-1 and dep-3 deployments, dep-3 is anti-affinity dep-1 and dep-2. A deployment specifies its membership in an anti-affinity group by referencing to all group names it pertains to as shown below.

<deployment>
<name>VPC-dep</name>
 <deployment_groups>
  <anti_affinity_group>VPC-ANTI-AFFINITY</anti_affinity_group>
  <anti_affinity_group>VPNAAS-ANTI-AFFINITY</anti_affinity_group>
 </deployment_groups>
….
</deployment>

In the above example, VPC-dep is in 2 anti-affinity groups; any other deployment that references one of these 2 groups will have an anti-affinity relationship with VPC-dep.

Anti-affinity group is an example of placement group. Anti-affinity group has the following properties in ESC:

• The placement group need not be created or deleted.

• Placement groups can be referenced for the first time by one deployment as well as multiple deployments in parallel.

• Placement rules are applicable during any deployment phase of a service including

  • Initial deployment

  • Scale out

  • VM group update addition

  • VM group minimum scaling update (increasing minimum scaling to add VMs)

  • Recovery

A multiple VIM deployment, supports Inter-deployment anti-affinity. However, ESC rejects a deployment

• If the inter-deployment anti-affinity policy is defined between a multiple VIM deployment (with locators within VM groups) and a default VIM deployment (without locators).

• If all the deployments of an inter-deployment anti-affinity group are not deployed on the same VIM (with same vim_id). For more details on a multiple VIM deployment, see Deploying VNFs on Multiple OpenStack VIMs.

Intra Group Affinity Policy

The VNFs with the same VM group can be deployed on the same host.

During deployment, ESC deploys the first VM as an anchor VM for affinity. All the other VMs that follow the same affinity rule will be deployed to the same host as the anchor VM. The anchor VM deployment helps to optimize the resource usage.

Example for Intra Group Affinity Policy:

…
<vm_group>
<name>vm-gp</name>
…
<placement>
<type>zone_host</type>
<enforcement>strict</enforcement>
<zone>cluster1</zone>
</placement>
<placement>
<type>affinity</type>
<enforcement>strict</enforcement>
</placement>
…

Note	Only strict attribute is supported for enforcement.

Note	Affinity and anti-affinity policy with a host placement policy is incorrect and may cause deployment failure.

Note	Host placement alone (without affinity and anti-affinity placement policy within a VM group) can be used to achieve intra group affinity.

Intra Group Anti-Affinity

The VNFs with the same VM group can be deployed in different hosts. During deployment ESC deploys VNFs with the same VM group one after the other. At the end of each VNF deployment, ESC records its host to a list. At the beginning of each VNF’s deployment, ESC deploys the VNF to a computing-host that is not in the list. If all the available computing-host(s) are in the list, ESC fails the whole deployment.

Example for Intra Group Anti-Affinity Policy:

…
<vm_group>
<name>vm-gp</name>
…
<placement>
<type>zone_host</type>
<enforcement>strict</enforcement>
<zone>cluster1</zone>
</placement>
<placement>
<type>anti_affinity</type>
<enforcement>strict</enforcement>
</placement>

Cluster Placement

All VMs in a VM group can be deployed to a cluster. For example, all VMs in a vm group CSR-gp1 can be deployed to cluster ott-cluster2.

Note	The VMware vCenter cluster must be created by the administrator.

Example for cluster placement:

<name>CSR-gp1</name>
	         <placement>
		             <type>zone_host</type>
		             <enforcement>strict</enforcement>
		             <zone>ott-cluster2</zone>
           </placement>

Host Placement

All VMS in a VM group can be deployed to a host. For example, all VMs in the vm group CSR-gp1 will be deployed to host 10.2.0.2.

<name>CSR-gp1</name>
           <placement>
             <type>zone_host</type>
	            <enforcement>strict</enforcement>
	             <host>10.2.0.2</host>
            </placement> 

Inter Group Affinity Policy

The VMs in different VM groups can be deployed to the same host. For example, all VMs in the VM group ASA-gp1 can be deployed to the same host as the VMs in the VM group CSR-gp1.

During deployment ESC deploys the first VM as an anchor VM. All other VMs that follow the same affinity rule will be deployed to the same host as the anchor VM.

Note	To ensure that the inter-group affinity rules are applied within a single cluster, verify that all VM groups in a deployment are specified to the same cluster (<zone> in esc data_model).

Example for Inter Group Affinity Policy:

<deployment>
<deployment>
<name>test-affinity-2groups</name>
<policies>
<placement>
<target_vm_group_ref>CSR-gp1</target_vm_group_ref>
<type>affinity</type>
<vm_group_ref>CSR-gp2</vm_group_ref>
<vm_group_ref>ASA-gp1</vm_group_ref>
<enforcement>strict</enforcement>
</placement>
</policies>

Inter Group Anti-Affinity Policy

The VNFs are in the same deployment, but different VM groups can be explicitly deployed in different hosts. During deployment, ESC deploys the first VNF of the target VM group, and records its host to a list at the end. ESC then deploys the first VNF of each reference VM groups, ensure the VNFs are not deployed to the host in the list. Then, the second VNF of the target VM group, the second VNF of each reference VM group, and rest of the VNFs accordingly.

Example for Inter Group Anti-Affinity Policy:

<deployment>
<deployment>
<name>vm-groups</name>
<policies>
<placement>
<target_vm_group_ref>CSR-gp1</target_vm_group_ref>
<type>anti_affinity</type>
<vm_group_ref>CSR-gp2</vm_group_ref>
<vm_group_ref>ASA-gp1</vm_group_ref>
<enforcement>strict</enforcement>
</placement>
</policies>

A placement group tag is added under policies. Each <placement_group> contains the following:

• name—name unique per deployment.

• type—affinity or anti_affinity

• enforcement—strict

• vm_group—the content of each vm_group must be a vm group name listed under the same deployment.

The placement group tag is placed within the placement policy. The placement policy describes the relationship between the target vm group and the vm group members. The placement_group policy describes mutual relationship among all vm group members. The placement group policy is not applicable for target vm group.

The datamodel is as follows:

<policies>
	<placement_group>
		<name>placement-affinity-1</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g1</vm_group>
		<vm_group>t1g2</vm_group>
		<vm_group>t1g7</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-affinity-2</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g3</vm_group>
		<vm_group>t1g4</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-affinity-3</name>
		<type>affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g5</vm_group>
		<vm_group>t1g6</vm_group>
	</placement_group>
	<placement_group>
		<name>placement-anti-affinity-1</name>
		<type>anti_affinity</type>
		<enforcement>strict</enforcement>
		<vm_group>t1g1</vm_group>
		<vm_group>t1g3</vm_group>
		<vm_group>t1g5</vm_group>
	</placement_group>
</policies>

Note

In the new placement group tag under policies, the <target_vm_group_ref> and <vm_group_ref> are replaced with <vm_group>. The ref based affinity and antiaffinity tags are deprecated. The placement group policy is applicable for inter group affinity and anti-affinity policies only. You cannot use both placement and placement group tags together in the inter group affinity and anti-affinity policies. The placement group name tag must be unique for each placement group policy.

Limitations