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.

...

The following is the schema for a valid candidate: candidate_id uniquely identifies a candidate. Currently, it is either a Service Instance ID or Cloud Region ID. candidate_type identifies the type of the candidate. Currently, it is either cloud or service. inventory_type is defined as described in *Inventory Provider Criteria inventory_provider identifies the inventory from which the candidate was drawn. host_id is an ID of a specific host (used only when referring to service/existing inventory). cost is expressed as a unitless number. location_id is always a location ID of the specified location type (e.g., for a type of cloud this will be an Cloud Region ID). location_type is an inventory provider supported location type. latitude is a valid latitude corresponding to the locationid. longitude is a valid longitude corresponding to the *locationid. city (Optional) city corresponding to the location_id. state (Optional) state corresponding to the locationid. country (Optional) country corresponding to the *locationid. region (Optional) geographic region corresponding to the location_id. complex_name (Optional) Name of the complex corresponding to the locationid. ``cloudowner(Optional) refers to the *cloud owner* (e.g.,azure,aws,att, etc.). *cloudregionversion(Optional) is an inventory provider supported version of the cloud region. *physicallocationid`` (Optional) is an inventory provider supported CLLI code corresponding to the cloud region.

Examples

Code Block

language	js
title	service candidate

{
	"candidate_id": "1ac71fb8-ad43-4e16-9459-c3f372b8236d",
	"candidate_type": "service",
	"inventory_type": "service",
	"inventory_provider": "aai",
	"host_id": "vnf_123456",
	"cost": "100",
	"location_id": "DLLSTX55",
	"location_type": "azure",
	"latitude": "32.897480",
	"longitude": "-97.040443",
	"city": "Dallas",
	"state": "TX",
	"country": "USA",
	"region": "US",
	"complex_name": "dalls_one",
	"cloud_owner": "att-aic",
	"cloud_region_version": "1.1",
	"physical_location_id": "DLLSTX55",
}

...

Code Block

language	js
title	cloud candidate

{
      "candidate_id": "NYCNY55",
      "candidate_type": "cloud",
      "inventory_type": "cloud",
      "inventory_provider": "aai",

Questions * Currently, candidates are either service instances or cloud regions. As new services are on-boarded, this can be evolved to represent different types of resources.

Examples

The following examples illustrate two demands:

vGMuxInfra: A vGMuxInfra service, drawing candidates of type service from the inventory. Only candidates that match the customer_id and orchestration-status will be included in the search space.
vG: A vG, drawing candidates of type service and cloud from the inventory. Only candidates that match the customer_id and provisioning-status will be included in the search space.

...

"cost":

...

"100",

...

"location_

...

id":

...

"NYCNY55",

...

 "location_type":

...

"azure",

...

"latitude":

...

"40.7128",

...

 "longitude": "-74.0060",

...

"city": "New York",

...

Questions * Do we need to support cost as a function ?

Constraints

A Constraint is used to eliminate inventory candidates from one or more demands that do not meet the requirements specified by the constraint. Since reusability is one of the cornerstones of HAS, Constraints are designed to be service-agnostic, and is parameterized such that it can be reused across a wide range of services. Further, HAS is designed with a plug-in architecture that facilitates easy addition of new constraint types.

Constraints are denoted by a constraints key. Each constraint is uniquely named and set to a dictionary containing a constraint type, a list of demands to apply the constraint to, and a dictionary of constraint properties.

Considerations while using multiple constraints Constraints should be treated as a unordered list, and no assumptions should be made as regards to the order in which the constraints are evaluated for any given demand. All constraints are effectively AND-ed together. Constructs such as "Constraint X OR Y" are unsupported. * Constraints are reducing in nature, and does not increase the available candidates at any point during the constraint evaluations.

Schema

...

| Key | Value | |---------------------|-------------| | CONSTRAINT_NAME | Key is a unique name. | | type | The type of constraint. See Constraint Types for a list of currently supported values. | | demands | One or more previously declared demands. If only one demand is specified, it may appear without list markers ([]). | | properties (Optional) | Properties particular to the specified constraint type. Use if required by the constraint. |

constraints:
  CONSTRAINT_NAME_1:
    type: CONSTRAINT_TYPE
    demands: DEMAND_NAME | [DEMAND_NAME_1, DEMAND_NAME_2, ...]
    properties: PROPERTY_DICT

  CONSTRAINT_NAME_2:
    type: CONSTRAINT_TYPE
    demands: DEMAND_NAME | [DEMAND_NAME_1, DEMAND_NAME_2, ...]
    properties: PROPERTY_DICT

  ...

Constraint Types

...

"state": "NY",
      "country": "USA",
      "region": "US",
      "complex_name": "ny_one",
      "cloud_owner": "att-aic",
      "cloud_region_version": "1.1",
      "physical_location_id": "NYCNY55"
}

Questions * Currently, candidates are either service instances or cloud regions. As new services are on-boarded, this can be evolved to represent different types of resources.

Examples

The following examples illustrate two demands:

vGMuxInfra: A vGMuxInfra service, drawing candidates of type service from the inventory. Only candidates that match the customer_id and orchestration-status will be included in the search space.
vG: A vG, drawing candidates of type service and cloud from the inventory. Only candidates that match the customer_id and provisioning-status will be included in the search space.

demands:
  vGMuxInfra:
  - inventory_provider: aai
    inventory_type: service
    service_type: vG_Mux
    attributes:
      customer-id: some_company
      orchestration-status: Activated
  vG:
  - inventory_provider: aai
    inventory_type: service
    service_type: vG
    attributes:
      customer-id: some_company
      provisioning-status: provisioned
  - inventory_provider: aai
    inventory_type: cloud

Questions * Do we need to support cost as a function ?

Constraints

A Constraint is used to eliminate inventory candidates from one or more demands that do not meet the requirements specified by the constraint. Since reusability is one of the cornerstones of HAS, Constraints are designed to be service-agnostic, and is parameterized such that it can be reused across a wide range of services. Further, HAS is designed with a plug-in architecture that facilitates easy addition of new constraint types.

Constraints are denoted by a constraints key. Each constraint is uniquely named and set to a dictionary containing a constraint type, a list of demands to apply the constraint to, and a dictionary of constraint properties.

Considerations while using multiple constraints Constraints should be treated as a unordered list, and no assumptions should be made as regards to the order in which the constraints are evaluated for any given demand. All constraints are effectively AND-ed together. Constructs such as "Constraint X OR Y" are unsupported. * Constraints are reducing in nature, and does not increase the available candidates at any point during the constraint evaluations.

Schema

Key	Value
`CONSTRAINT_NAME`	Key is a unique name.
`type`	The type of constraint. See Constraint Types for a list of currently supported values.
`demands`	One or more previously declared demands. If only one demand is specified, it may appear without list markers (`[]`).
`properties` (Optional)	Properties particular to the specified constraint type. Use if required by the constraint.

| Key | Value | |---------------------|-------------| | CONSTRAINT_NAME | Key is a unique name. | | type | The type of constraint. See Constraint Types for a list of currently supported values. | | demands | One or more previously declared demands. If only one demand is specified, it may appear without list markers ([]). | | properties (Optional) | Properties particular to the specified constraint type. Use if required by the constraint. |

constraints:
  CONSTRAINT_NAME_1:
    type: CONSTRAINT_TYPE
    demands: DEMAND_NAME | [DEMAND_NAME_1, DEMAND_NAME_2, ...]
    properties: PROPERTY_DICT

  CONSTRAINT_NAME_2:
    type: CONSTRAINT_TYPE
    demands: DEMAND_NAME | [DEMAND_NAME_1, DEMAND_NAME_2, ...]
    properties: PROPERTY_DICT

  ...

Constraint Types

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.
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.

| Type | Description | |

Note: Constraint names marked "Deferred" *will not

Threshold Values

Constraint property values representing a threshold may be an integer or floating point number, optionally prefixed with a comparison operator: =, <, >, <=, or >=. The default is = and optionally suffixed with a unit.

Whitespace may appear between the comparison operator and value, and between the value and units. When a range values is specified (e.g., 10-20 km), the comparison operator is omitted.

Each property is documented with a default unit. The following units are supported:

...

| Unit | Values | Default | |------------|---------|---------------------|----------| | Currency | USD | USD | | Time | ms, sec | ms | | Distance | km, mi | km | | Throughput | Kbps, Mbps, Gbps | Mbps |

Attribute

Constrain one or more demands by one or more attributes, expressed as properties. Attributes are mapped to the inventory provider specified properties, referenced by the demands. For example, properties could be hardware capabilities provided by the platform (flavor, CPU-Pinning, NUMA), features supported by the services, etc.

Schema

...

| | 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. | | 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. |

Note: Constraint names marked "Deferred" *will not

Threshold Values

Constraint property values representing a threshold may be an integer or floating point number, optionally prefixed with a comparison operator: =, <, >, <=, or >=. The default is = and optionally suffixed with a unit.

Whitespace may appear between the comparison operator and value, and between the value and units. When a range values is specified (e.g., 10-20 km), the comparison operator is omitted.

Each property is documented with a default unit. The following units are supported:

Unit	Values	Default
Currency	USD	USD
Time	`ms`, `sec`	`ms`
Distance	`km`, `mi`	`km`
Throughput	`Kbps`, `Mbps`, `Gbps`	`Mbps`

| Unit | Values | Default

| Property | Value | |--------------|-------------------------------------------------------------| | evaluate | Opaque dictionary of attribute name and value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin. |

Note: Attribute values are not detected/parsed as thresholds by the Homing framework. Such interpretations and evaluations are inventory provider-specific and delegated to the corresponding plugin

constraints:
  sriov_nj:
    type: attribute
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      evaluate:
        cloud_version: 1.1
        flavor: SRIOV
        subdivision: US-TX
        vcpu_pinning: True
        numa_topology: numa_spanning

Proposal: Evaluation Operators

To assist in evaluating attributes, the following operators and notation are proposed:

...

| Operator | Name | Operand | |--------------|-----------|--------------------------|----------------------| | eq Currency | == | Any object (string, number, list, dict) | | ne | != | | | lt | < | A number (strings are converted to float) | | gt | > | | | lte | <= | | | gte | >= | | | any | Any | A list of objects (string, number, list, dict) | | all | All | | | regex | RegEx | A regular expression pattern |

Example usage:

constraints:
  sriov_nj:
    type: attribute
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      evaluate:
        cloud_version: {gt: 1.0}
        flavor: {regex: /^SRIOV$/i}
        subdivision: {any: [US-TX, US-NY, US-CA]}

Distance Between Demands

Constrain each pairwise combination of two or more demands by distance requirements.

Schema

...

Attribute

Constrain one or more demands by one or more attributes, expressed as properties. Attributes are mapped to the inventory provider specified properties, referenced by the demands. For example, properties could be hardware capabilities provided by the platform (flavor, CPU-Pinning, NUMA), features supported by the services, etc.

Schema

Property	Value
`evaluate`	Opaque dictionary of attribute name and value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin.

| Property | Value | |--------------| Name | Value | |--------------|-------------------------------------------------------------| | distance | Distance between demands, measured by the geographic path. |

The constraint is applied between each pairwise combination of demands. For this reason, at least two demands must be specified, implicitly or explicitly.

evaluate | Opaque dictionary of attribute name and value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin. |

Note: Attribute values are not detected/parsed as thresholds by the Homing framework. Such interpretations and evaluations are inventory provider-specific and delegated to the corresponding plugin

constraints:
  sriov_njconstraints:
  distance_vnf1_vnf2:
    type: distance_between_demandsattribute
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      distanceevaluate: < 250 km

Distance To Location

Constrain one or more demands by distance requirements relative to a specific location.

Schema

...


        cloud_version: 1.1
        flavor: SRIOV
        subdivision: US-TX
        vcpu_pinning: True
        numa_topology: numa_spanning

Proposal: Evaluation Operators

To assist in evaluating attributes, the following operators and notation are proposed:

Operator	Name	Operand
`eq`	`==`	Any object (string, number, list, dict)
`ne`	`!=`
`lt`	<	A number (strings are converted to float)
`gt`	>
`lte`	<=
`gte`	>=
`any`	Any	A list of objects (string, number, list, dict)
`all`	All
`regex`	RegEx	A regular expression pattern

| Operator | Name | Operand | |--------------| Property | Value | |--------------|-----------|-------------------------------------------------| | eq | distance | Distance between demands, measured by the geographic path. | | location | A previously declared location. |The constraint is applied between each demand and the referenced location, not across all pairwise combinations of Demands. == | Any object (string, number, list, dict) | | ne | != | | | lt | < | A number (strings are converted to float) | | gt | > | | | lte | <= | | | gte | >= | | | any | Any | A list of objects (string, number, list, dict) | | all | All | | | regex | RegEx | A regular expression pattern |

Example usage:

constraints:
  distancesriov_vnf1_locnj:
    type: distance_to_locationattribute
    demands: [my_vnf_demand, my_other_vnf_demand, another_vnf_demand]
    properties:
      evaluate:
       distance: < 250 km
  cloud_version: {gt: 1.0}
        flavor: {regex: /^SRIOV$/i}
        subdivision: location: LOCATION_ID

Instance Fit

Constrain each demand by its service requirements.

Requirements are sent as a request to a service controller. Service controllers are defined by plugins in Homing (e.g., sdn-c).

A service controller 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

...

{any: [US-TX, US-NY, US-CA]}

Distance Between Demands

Constrain each pairwise combination of two or more demands by distance requirements.

Schema

Name	Value
`distance`	Distance between demands, measured by the geographic path.

| Name | Value | |--------------|----------| Property | Description | |----------------|-----------------------------------| | controller | Name of a service controller. | | request | Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin. | distance | Distance between demands, measured by the geographic path. |

The constraint is applied between each pairwise combination of demands. For this reason, at least two demands must be specified, implicitly or explicitly.

constraints:
  checkdistance_forvnf1_availabilityvnf2:
    type: instancedistance_between_fitdemands
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      controllerdistance: sdn-c
<      request: REQUEST_DICT

Region Fit

Constrain each demand's inventory candidates based on inventory provider membership.

Requirements are sent as a request to a service controller. Service controllers are defined by plugins in Homing (e.g., sdn-c).

A service controller 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

...

Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin.

250 km

Distance To Location

Constrain one or more demands by distance requirements relative to a specific location.

Schema

Property	Value
`distance`	Distance between demands, measured by the geographic path.
`location`	A previously declared location.

| Property | Value | |--------------|--------| Property | Description | |----------------|------------------------------------| | distance | Distance between demands, measured by the geographic path. | | location | A previously declared location. |

The constraint is applied between each demand and the referenced location, not across all pairwise combinations of Demands.

constraints:
  distance_vnf1_loc:
    type: distance_to_location
    demands: [my_vnf_demand, my_other_vnf_demand, another_vnf_demand]
    properties:
      distance: < 250 km
      location: LOCATION_ID

Instance Fit

Constrain each demand by its service requirements.

Requirements are sent as a request to a service controller. Service controllers are defined by plugins in Homing (e.g., sdn-c).

A service controller 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 service controller.
`request`	Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin.

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

constraints:
  check_for_availability:
    type: instance_fit
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      controller: sdn-c
      request: REQUEST_DICT

Region Fit

Constrain each demand's inventory candidates based on inventory provider membership.

Requirements are sent as a request to a service controller. Service controllers are defined by plugins in Homing (e.g., sdn-c).

A service controller 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 service controller.

request

Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin.

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

constraints:
  check_for_membership:
    type: region_fit
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      controller: sdn-c
      request: REQUEST_DICT

Zone

Constrain two or more demands such that each is located in the same or different zone category.

Zone categories are inventory provider-defined, based on the demands being constrained.

Schema

Property	Description
`qualifier`	Zone qualifier. One of `same` or `different`.
`category`	Zone category. One of `disaster`, `region`, `complex`, `time`, or `maintenance`.

| Property | Value | |---------------|-------------------------------------------------------------| | qualifier | Zone qualifier. One of same or different. | | category | Zone category. One of disaster, region, complex, time, or maintenance. |

For example, to place two demands in different disaster zones:

constraints:
  vnf_diversity:
    type: zone
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      qualifier: different
      category: disaster

Or, to place two demands in the same region:

constraints:
  vnf_affinity:
    type: zone
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      qualifier: same
      category: region

Notes

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.

| 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

constraints:
  check_for_membership:
    type: region_fit
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      controller: sdn-c
      request: REQUEST_DICT

Zone

Constrain two or more demands such that each is located in the same or different zone category.

Zone categories are inventory provider-defined, based on the demands being constrained.

Schema

Property	Description
`qualifier`	Zone qualifier. One of `same` or `different`.
`controller`	Name of a vim controller. (e.g., `multicloud`)
`request`	Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the vim controller via a plugin	`category`	Zone category. One of `disaster`, `region`, `complex`, `time`, or `maintenance` .

| Property | Value Description | |---------------|---------------------|-----------------------------------------| | qualifier | Zone qualifier. One of same or different. | | category | Zone category. One of disaster, region, complex, time, or maintenance. |

For example, to place two demands in different disaster zones:

constraints:
  vnf_diversity:
    type: zone
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      qualifier: different
      category: disaster

Or, to place two demands in the same region:

-----| | 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: constraints:
  vnf_affinity:
    type: zone
    demands: [my_vnf_demand, my_other_vnf_demand]

      properties:

          qualifiercontroller: same
multicloud
          category: region

Notes

...

request: REQUEST_DICT

Inventory Group

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

...

Space shortcuts

Page tree

Versions Compared

Old Version 7

New Version Current

Key

Homing Specification Guide

Parameters

Constraints

Constraint Types

Constraints

Constraint Types

Threshold Values

Attribute

Threshold Values

Proposal: Evaluation Operators

Distance Between Demands

Attribute

Distance To Location

Proposal: Evaluation Operators

Instance Fit

Distance Between Demands

Region Fit

Distance To Location

Instance Fit

Region Fit

Zone

HPA & Cloud Agnostic Intent

VIM Fit

Zone

Inventory Group

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 7

New Version Current

Key

Homing Specification Guide

Parameters

Constraints

Constraint Types

Constraints

Constraint Types

Threshold Values

Attribute

Threshold Values

Proposal: Evaluation Operators

Distance Between Demands

Attribute

Distance To Location

Proposal: Evaluation Operators

Instance Fit

Distance Between Demands

Region Fit

Distance To Location

Instance Fit

Region Fit

Zone

HPA & Cloud Agnostic Intent

VIM Fit

Zone

Inventory Group