OpenStack vs IFA005006 Gaps

Introduction

There is an ongoing in ETSI NFV's TST WG to find the gaps between the ETSI NFV IaaS API (IFA005 and IFA006) and the API-s of OpenStack projecs with tc:approved-release flag in Ocata. In this work the following experts are contributing beside the members of TST WG: Giacomo Bernini (Nextworks), Dmitriy Andrushko (Mirantis) and Elian Kraja (Nextworks). The following list are the gaps discovered so far.

[GAP-01] Affinity resource list scope

Description: Allocate Virtualised Compute Resource contains AffinityOrAntiAffinityConstraint which offers two alternative ways to define affinity rules: affinityAntiAffinityResourceList and affinityAntiAffinityResourceGroup.
It is not mandatory to support both and OpenStack supports only affinityAntiAffinityResourceGroup type of method.

[GAP-03] Resource reservation for calendar time

Description: Virtualised Compute Resources Capacity Management Interface (7.4.4), Virtualised Network Resources Capacity Management Interface (7.3.4), Virtualised Storage Resources Capacity Management Interface (7.5.4) assumes that it is possible to reserve resources for a given time period, while this is not possible in OpenStack.
OPNFV Promise plans to cover this functionality by with the usage of Blazar.

[GAP-04] Capacity query for a time period

Description: Query Compute Capacity operation (7.3.4.2) contains a timePeriod to define a time period when the capacity is queried. As in OpenStack it is not possible to reserve resources for a given time period it is also not possible to query the capacity for a time period.

[GAP-05] Publish subscribe to resource changes

Description: Virtualised Compute Resources Capacity Management Interface (7.3.4), Virtualised Network Resources Capacity Management Interface (7.4.4) and Virtualised Storage Resources Capacity Management Interface (7.5.4) define a publish subscribe mechanism where it is possible to subscibe to changes of the different resources. OpenStack does not support publish subscribe, long polling nor a websocket based mechanism to watch the changes of different resources. OpenStack Compute and Storage API-s support simple query and return with the actual state of the resource. Ceilometer is capable to send events to an external service, but subscription to these events are not exposed to the API. Using a publish subscribe mechanism would need a bidirectional communication which in case of http based protocols assumes a web server on both sides. Long polling does not need bidirectional communication, but the connection can be interrupted by intermediate network devices. A websocket based publish notify solution would be ideal from connectivity perspective (websocket uses only one TCP connection what is already open, so there is no need to open new connection), but it is a solution beyond the capabilities of the plain http based REST API-s. Also in case of websockets the protocol is not defined and the OpenStack would become statefull what negatively affects the scalability and reliability.

[GAP-06] Bandwidth per Network Interface

Description: Virtualised Compute Resources Management Interface (7.3.1), in Allocate Virtualised Compute Resource operation output (7.3.1.2.3), defines VirtualCompute (8.4.3.2) as main output, where bandwidth parameter is mandatory under virtualNetworkInterface. However, in OpenStack bandwidth information is not available per port, while it can be set and retrieved (as optional attribute) per network via Neutron Networks QoS (neutron-qos). The same applies to: i) Query Virtualised Compute Resource operation (7.3.1.3.3), that still returns a VirtualCompute; ii) and to Update Virtualised Compute Resource operation (7.3.1.4), that defines bandwidth under networkInterfaceNew and networkInterfaceUpdate.
The functionality exist in OpenStack, but it is not visible in the API documentation of the port operations.

[GAP-07] Acceleration Capability in Update Compute

Description: Virtualised Compute Resources Management Interface (7.3.1), in the Update Virtualised Compute Resource operation (7.3.1.4), defines the option to set or update accelerationCapability under networkInterfaceNew and networkInterfaceUpdate, which are used to attach new ports/network-interfaces or update existing ones to a compute resource (i.e. an OpenStack Server). These operations are mapped into OpenStack with Nova Server update (POST ​/servers/{server_id}/os-interface) or Neutron Port create (POST /ports). OpenStack (both in Nova Server update and Neutron Port create) does not allow to directly set acceleration capabilities over a Port. Acceleration capabilities can be managed as part of the Nova Compute Flavor operations (nova-flavors), in particular by means of specific network-related extra-specs (extra-specs).