OpenStack vs IFA005006 Gaps

Introduction

There is an ongoing activity 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-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.4.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).

[GAP-08] Minimum Bandwidth per Network

Description: Virtualised Network Resources Management Interface (7.4.1), in the Allocate Virtualised Network Resource operation (7.4.1.2), when considering the allocation of a virtual network, defines a mandatory bandwidth attribute in the VirtualNetworkData IE (8.4.4.2). This bandwidth parameter is defined as the minimum guaranteed bandwidth for the network to be created. The same applies to VirtualNetwork IE (8.4.5.2), that is returned in the Allocate Virtualised Network Resource response. This operation is mapped into OpenStack with the creation of a Neutron QoS policy (qos) to be then associated with the Neutron network. However, with Neutron QoS policies is not possibile to define a minimum guaranteed bandwidth per network, but only bandwidth limits.

[GAP-09] Subnet Operational State

Description: Virtualised Network Resources Management Interface (7.4.1), in the Allocate Virtualised Network Resource operation (7.4.1.2), when considering the allocation of a subnet, defines a mandatory operationalState parameter in the NetworkSubnet IE (8.4.5.3), that is returned Allocate Virtualised Network Resource response. This operationalState parameter is defined as an Enum {enabled,disabled}. This operation is mapped into OpenStack with the creation of a Neutron Subnet (Subnets). Neutron does not include any operational State for the Subnet.

[GAP-10] Virtualised Network Resources Capacity Management Interface

Description: Virtualised Network Resources Capacity Management Interface (7.4.4) specifies number of operations related to network capacity and usage reporting. As of Ocata release OpenStack is missing capacity management for networking resources. There is a general user story focused on a capacity management at OpenStack, but at this moment no appropriate blueprints and implementation roadmap. Additionally IFA005 spec doesn't specify which network resources are subject for "Capacity Management" operations, i.e. Network Bandwidth, QoS parameters, Ports, IPs etc. Depending on a definition of the "Network Resources", some of the existing existing OpenStack features might be used, for ex. Quota interface to get information about allocated/used networks, subnets, FIPs, etc.

[GAP-11] Change Network Forwarding Path (NFP) State operation

Description: In Network Forwarding Path Management Interface (7.4.5), Change NFP State operation (7.4.5.5) should be used to request changing the state (enable or disable) of an NFP. Assuming that Neutron Service Functions Chaining (SFC) is logically equal implementation of the NFP entity defined in section 7.4.5, OpenStack implementation is missing operation which is capable to enable/disable SFC. At the moment of review only full create/delete operations for port-pairs, port-groups and port-chains required to enable or disable SFC at the OpenStack. Note: At this moment Neutron SFC functionality is available with OVS driver only

[GAP-12] Creation of Resource Quota

Description: In Virtualised Resource Quota Interfaces (7.9), dedicated Create Resource Quota operations are defined for Compute (7.9.1.2), Networking (7.9.2.2) and Storage (7.9.3.2) resources. These IFA operations are intended to be used for restricting the amount of compute, networking and storage resources of an "infrastructure resource group" (see QUOTA-1) to a given quota. OpenStack defines Quotas as operational limits over a set of compute, networking and storage resources, which are enforced at a project level. OpenStack Nova, Neutron and Cinder do not provide any operation for explicit creation of compute (nova-quotas), networking (neutron-quotas) and storage (storage-quotas) quotas. However, each OpenStack tenant has a default set of assigned quotas at its creation, which can be updated at runtime via dedicated Nova (nova-quotas-update), Neutron (neutron-quotas-update) and Cinder (cinder-quotas-update) operations. Moreover, default compute quotas can be updated by means of a specific Nova API (nova-default-quota-update), that changes the default values for future projects creations.

[GAP-13] Filtered and Bulk Queries of Virtualised Resource Quotas

Description: In Virtualised Resource Quota Interfaces (7.9), specific Query Resource Quota operations are defined for Compute (7.9.1.3), Networking (7.9.2.3) and Storage (7.9.3.3) resources. These IFA operations define a queryQoutaFilter input parameter to be used as filter to express what quota information to be retrieved. OpenStack supports Quotas query operations for compute, networking and storage resources, per single project and without any input filtering option or attribute. Indeed, OpenStack Nova (nova-quotas-query), Neutron (neutron-quotas-query) and Cinder (cinder-quotas-query) quota queries return the full quota information of the given project, rather than a bulk of quotas as defined by IFA in the Query Resource Quota operation responses.

[GAP-14] Affinity/Anti-Affinity Constraints for volume migration

Description: Migrate Virtualised Storage Resource operation request (7.5.1.8.2), assumes that affinityConstraint or antiAffinityConstraint might be specified in the request. However, in the OpenStack Ocata release Cinder is not supporting such constraints during volume migration.

[GAP-15] Required Filtering capabilities are missing in the OpenStack block storage service

Description: Query Storage Capacity operation request (7.5.4.2.2) considers number of mandatory filters have to be specified in the message body, such as storageResourceTypeId, resourceCriteria and timePeriod. While, information like storageResourceTypeId, might be included in a form of the metadata for a given volume, further it's not possible filter output from the block storage service by none of these parameters. For example it's not possible to query for "All volumes in a given Availability Zone". Additionally, according IFA005 timePeriod key relates to resource reservation capabilities (i.e. storage reservation). However, block storage reservation is not available in a OpenStack resource reservation service (i.e. Blazar) in the Ocata release cycle.

[GAP-16] Data included in the Storage Capacity operation response

Description: According to IFA005, Query Storage Capacity operation response (7.5.4.2.3) should include information about availableCapacity, reservedCapacity, totalCapacity, allocatedCapacity. At this moment Cinder API doesn't provide summary information about used storage by allocated volumes, but technically it is possible to calculate allocated storage manually using Cinder output on a GET v3/{tenant id}/volumes/detail request. In the meantime, querying Cinder for reservedCapacity is not valid, as this service does not managing resource reservation. Additionally it's not possible to retrieve information similar by nature to availableCapacity (i.e. amount of available storage), information in missing in case of LVM storage driver, but potentially other back-end storage drivers have the same issue.

[GAP-17] Resource Reservation capabilities are missing in OpenStack

Description: IFA005 and IFA006 specifies "Virtualised Resources Reservation Management" group of interfaces which have to provide reservation of the virtualised Compute, Networking and Storage resources for a given time period, what can be from now to the infinity and generate appropriate notifications upon certain events. However, OpenStack Blazar project, which is focused on a resource reservation as of OpenStack Ocata release does not have capabilities to reserve virtualized Compute, Networking or Storage resources - https://review.openstack.org/#/c/459533/18/doc/source/devref/specs/pike/new-instance-reservation.rst. In Ocata OpenStack release only compute node, i.e. full hypervisor reservation is supported via host plugin - https://review.openstack.org/gitweb?p=openstack/blazar.git;a=blob;f=blazar/plugins/oshosts/host_plugin.py.

[GAP-18] Notifications of Virtualised Resource Quota changes

Description: In Virtualised Resource Quota Interfaces (7.9), IFA defines a mechanism to subscribe to changes on quota of virtualised resources (7.9.4.2), and to provide such notification to the subscribed consumer (7.9.4.3). OpenStack does not provide any explicit notification related to quota changes, for neither compute, nor networking, nor storage resources. The only option available is to subscribe to OpenStack Project related notification events provided by Keystone (keystone-events). However, these events (generated for project create/update/delete) could be managed by Aodh as Alarms, but the main limitation is that they do not provide specific information on quota changes (keystone-events-payload)

[GAP-19] Creation of Performance Monitoring collection jobs on bulk of resources

Description: Virtualised Resources Performance Management Interface (7.7), in Create PM Job operation request (7.7.2.2), allows to define the set of resources for which performance information has to be collected by means of a specific resourceSelector parameter. This resourceSelector (type ObjectSelection defined in 8.5.2) can include multiple resource instance identifiers for performance collection in the same request. However, Gnocchi does not support the possibility of creating performance collection jobs over multiple resource instances within the scope of the same operation (gnocchi-resource-api). In Gnocchi, collection of metrics for different resource instances (e.g. VMs) need to be created/issued with different operations over Gnocchi resources.

[GAP-21] Performance Information Available Notification

Description: Virtualised Resources Performance Management Interface (7.7), in Subscribe (7.7.5) and Notify operations (7.7.6), defines a specific susbcription mechanism for receiving notifications from the VIM when new performance information is available for given virtualised resource instance IDs involved in previously created performance monitoring jobs. However, Gnocchi does not provide any mean to subscribe to notifications related to performance collection, and does not generate any event when new performance metrics are collected or available to be consumed. Indeed, Gnocchi offers query APIs to retrieve metrics collected for given resource instances (gnocchi-resource-api).

Deleted Gaps

[GAP-03] Resource reservation for calendar time

Description: Virtualised Compute Resources Capacity Management Interface (7.4.4), Virtualised Network Resources Capacity Management Interface (7.4.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.

ETSI NFV meets OpenStack workshop materials

• etherpad
• WhyWhatHow-ETSINFV
• OpenStack_ETSI_NFV_workshop
• ptg-denver-etsi-nfv-tst003-gaps-explained
• Glare
• NFV_PoCs_Plugtests
• OpenStack_Joint_meeting_TST