...

Homing Specification Guide

Updated: 10 October 201727 Mar 2018

This document describes the Homing Template format, used by the Homing service. It is a work in progress and subject to frequent revision.

...

Homing templates are defined in YAML and follow the structure outlined below.

homing_template_version: 20172018-1002-1001
parameters:
  PARAMETER_DICT
locations:
  LOCATION_DICT
demands:
  DEMAND_DICT
constraints:
  CONSTRAINT_DICT
reservations:
  RESERVATION_DICT
optimization:
  OPTIMIZATION

• homing_template_version: This key with value 20172016-1011-10 01 (or a later date) indicates that the YAML document is a Homing template of the specified version.
• parameters: This section allows for specifying input parameters that have to be provided when instantiating the homing template. Typically, this section is used for providing runtime parameters (like SLA thresholds), which in turn is used in the existing homing policies. The section is optional and can be omitted when no input is required.
• locations: This section contains the declaration of geographic locations. This section is optional and can be omitted when no input is required.
• demands: This section contains the declaration of demands. This section with at least one demand should be defined in any Homing template, or the template would not really do anything when being instantiated.
• constraints: This section contains the declaration of constraints. The section is optional and can be omitted when no input is required.
• reservations: This section contains the declaration of required reservations. This section is optional and can be omitted when reservations are not required.
• optimization: This section allows the declaration of an optimization. This section is optional and can be omitted when no input is required.

...

The value of homing_template_version tells HAS not only the format of the template but also features that will be validated and supported. Only one value is supported: 2017-10-10 in The following values are supported: "2016-11-01" or "2018-02-01" in the initial release of HAS.

homing_template_version: 20172018-1002-1001

Parameters

The parameters section allows for specifying input parameters that have to be provided when instantiating the template. Such parameters are typically used for providing runtime inputs (like SLA thresholds), which in turn is used in the existing homing policies. This also helps build reusable homing constraints where these parameters can be embedded design time, and it corresponding values can be supplied during runtime.

...

...

| Type | Description | |---------------------|-------------| | attribute | Constraint that matches the specified list of Attributes. | | distance_between_demands | Geographic distance constraint between each pair of a list of demands. | | distance_to_location | Geographic distance constraint between each of a list of demands and a specific location. | | instance_fit | Constraint that ensures available capacity in an existing service instance for an incoming demand. | | inventory_group | Constraint that enforces two or more demands are satisfied using candidates from a pre-established group in the inventory. | | region_fit | Constraint that ensures available capacity in an existing cloud region for an incoming demand. | | zone | Constraint that enforces co-location/diversity at the granularities of clouds/regions/availability-zones. | | license (Deferred) | License availability constraint. | | hpa | Constraint that recommends optimal flavor and cloud region based on required hardware platform capabilities for an incoming demand. | | vim_fit | Constraint that ensures capacity check with available capacity of VIMs based on incoming request. | | license (Deferred) | License availability constraint. | | network_between_demands (Deferred) | Network constraint between each pair of a list of demands. | | network_to_location (Deferred) | Network constraint between each of a list of demands and a specific location/address. |

...

• These categories could be any of the following: disaster_zone, region, complex, time_zone, and maintenance_zone. Really, we are talking affinity/anti-affinity at the level of DCs, but these terms may cause confusion with affinity/anti-affinity in OpenStack.

HPA & Cloud Agnostic Intent

Constrain each demand's inventory candidates based on available Hardware platform capabilities (HPA) and also intent support. Note that currently HPA and the cloud agnostic contraints will use the same schema.

Requirements mapped to the inventory provider specified properties, referenced by the demands. For example, properties could be hardware capabilities provided by the platform through flavors or cloud-region eg:(CPU-Pinning, NUMA), features supported by the services, etc.

Schema

| Property | Description | |----------------|-----------------------------------| | evaluate| List of id, type, directives and flavorProperties of each VM of the VNF demand. | 

constraints:
  hpa_constraint:
    type: hpa
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      evaluate:
        - [ List of {id: {vdu Name},
                     type: {type of VF}
                     directives: {DIRECTIVES LIST}, 
                     flavorProperties: HPACapability DICT} ]

HPACapability DICT :
  hpa-feature: basicCapabilities
  hpa-version: v1
  architecture: generic
  directives:
    - DIRECTIVES LIST
  hpa-feature-attributes:
    - HPAFEATUREATTRIBUTES LIST

DIRECTIVES LIST
  type: String
  attributes:
    - ATTRIBUTES LIST

ATTRIBUTES LIST
  attribute_name: String
  attribute_value: String

HPAFEATUREATTRIBUTES LIST
  hpa-attribute-key: String
  hpa-attribute-value: String
  operator: One of OPERATOR
  unit: String

OPERATOR : ['=', '<', '>', '<=', '>=', 'ALL']

VIM Fit

Constrain each demand's inventory candidates based on capacity check for available capacity of a list of VIMs

Requirements are sent as a request to a vim controller. vim controllers are defined by plugins in Homing (e.g., multicloud).

A vimcontroller plugin knows how to communicate with a particular endpoint (via HTTP/REST, DMaaP, etc.), obtain necessary information, and make a decision. The endpoint and credentials can be configured through plugin settings.

Schema

| Property | Description | |----------------|-----------------------------------| | controller | Name of a vim controller. | | request | Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the vim controller via a plugin. |

constraints:
  check_cloud_capacity:
    type: vim_fit
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      controller: multicloud
      request: REQUEST_DICT

Inventory Group

Constrain demands such that inventory items are grouped across two demands.

...