OpenStack vs IFA005006 Gaps - Revision history

Csatarig at 15:25, 16 May 2018

2018-05-16T15:25:25Z

← Older revision		Revision as of 16:25, 16 May 2018
Line 7:		Line 7:
	It is not mandatory to support both and OpenStack supports only affinityAntiAffinityResourceGroup type of method.<br />		It is not mandatory to support both and OpenStack supports only affinityAntiAffinityResourceGroup type of method.<br />
	<br />		<br />

	~~==[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. <br />
	~~OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].~~

	==[GAP-04] Capacity query for a time period==		==[GAP-04] Capacity query for a time period==
Line 67:		Line 63:
	==[GAP-21] Performance Information Available Notification==		==[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 ([http://gnocchi.xyz/rest.html#resources gnocchi-resource-api]).		'''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 ([http://gnocchi.xyz/rest.html#resources 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. <br />
			OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].

	= ETSI NFV meets OpenStack workshop materials =		= ETSI NFV meets OpenStack workshop materials =

Csatarig: /* [GAP-17] Resource Reservation capabilities are missing in OpenStack */

2018-05-16T15:18:43Z

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

← Older revision		Revision as of 16:18, 16 May 2018
Line 57:		Line 57:

	==[GAP-17] Resource Reservation capabilities are missing in OpenStack ==		==[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, Storage resources 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.		'''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 ==		==[GAP-18] Notifications of Virtualised Resource Quota changes ==

Csatarig at 15:16, 15 May 2018

2018-05-15T15:16:04Z

← Older revision		Revision as of 16:16, 15 May 2018
Line 1:		Line 1:
	= Introduction =		== 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).		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.		The following list are the gaps discovered so far.
	~~= Gaps =~~
	==[GAP-01] Affinity resource list scope==		==[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. <br />		'''Description:''' Allocate Virtualised Compute Resource contains AffinityOrAntiAffinityConstraint which offers two alternative ways to define affinity rules: affinityAntiAffinityResourceList and affinityAntiAffinityResourceGroup. <br />
Line 9:		Line 9:

	==[GAP-03] Resource reservation for calendar time==		==[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. <br />		'''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. <br />
	OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].		OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].

Line 16:		Line 16:

	==[GAP-05] Publish subscribe to resource changes==		==[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.		'''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 ==		==[GAP-06] Bandwidth per Network Interface ==
Line 39:		Line 39:

	== [GAP-11] Change Network Forwarding Path (NFP) State operation ==		== [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.<br />		'''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 <br />

			==[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 [https://nfvprivatewiki.etsi.org/index.php?title=GapsAndUserStories#.5BQUOTA-01.5D_Are_infrastructure_resource_group-s_OpenStack_tenants.3F 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 ([https://developer.openstack.org/api-ref/compute/#quota-sets-os-quota-sets nova-quotas]), networking ([https://developer.openstack.org/api-ref/networking/v2/?expanded=#quotas-extension-quotas neutron-quotas]) and storage ([https://developer.openstack.org/api-ref/block-storage/v3/#quota-sets-extension-os-quota-sets 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 ([https://developer.openstack.org/api-ref/compute/#update-quotas nova-quotas-update]), Neutron ([https://developer.openstack.org/api-ref/networking/v2/?expanded=update-quota-for-a-project-detail#update-quota-for-a-project neutron-quotas-update]) and Cinder ([https://developer.openstack.org/api-ref/block-storage/v3/#update-quotas-for-a-project cinder-quotas-update]) operations. Moreover, default compute quotas can be updated by means of a specific Nova API ([https://developer.openstack.org/api-ref/compute/#create-or-update-quotas-for-quota-class 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 ([https://developer.openstack.org/api-ref/compute/#show-a-quota nova-quotas-query]), Neutron ([https://developer.openstack.org/api-ref/networking/v2/?expanded=list-default-quotas-for-a-project-detail#list-quotas-for-a-project neutron-quotas-query]) and Cinder ([https://developer.openstack.org/api-ref/block-storage/v3/#show-quotas-for-a-project 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, Storage resources 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 ([https://docs.openstack.org/keystone/latest/advanced-topics/event_notifications.html 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 ([https://github.com/openstack/keystone/blob/stable/ocata/keystone/notifications.py 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 ([http://gnocchi.xyz/rest.html#resources 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 ([http://gnocchi.xyz/rest.html#resources gnocchi-resource-api]).

	= ETSI NFV meets OpenStack workshop materials =		= ETSI NFV meets OpenStack workshop materials =

Csatarig: Undo revision 3391 by Csatarig (talk)

2018-05-15T15:15:41Z

Undo revision 3391 by Csatarig (talk)

← Older revision		Revision as of 16:15, 15 May 2018
Line 1:		Line 1:
	== Introduction ==		= 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).		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.		The following list are the gaps discovered so far.
			= Gaps =
	==[GAP-01] Affinity resource list scope==		==[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. <br />		'''Description:''' Allocate Virtualised Compute Resource contains AffinityOrAntiAffinityConstraint which offers two alternative ways to define affinity rules: affinityAntiAffinityResourceList and affinityAntiAffinityResourceGroup. <br />
Line 9:		Line 9:

	==[GAP-03] Resource reservation for calendar time==		==[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. <br />		'''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. <br />
	OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].		OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].

Line 16:		Line 16:

	==[GAP-05] Publish subscribe to resource changes==		==[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.		'''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 ==		==[GAP-06] Bandwidth per Network Interface ==
Line 39:		Line 39:

	== [GAP-11] Change Network Forwarding Path (NFP) State operation ==		== [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~~ <br />		'''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.<br />

	~~==[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 [https://nfvprivatewiki.etsi.org/index.php?title=GapsAndUserStories#.5BQUOTA-01.5D_Are_infrastructure_resource_group-s_OpenStack_tenants.3F 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 ([https://developer.openstack.org/api-ref/compute/#quota-sets-os-quota-sets nova-quotas]), networking ([https://developer.openstack.org/api-ref/networking/v2/?expanded=#quotas-extension-quotas neutron-quotas]) and storage ([https://developer.openstack.org/api-ref/block-storage/v3/#quota-sets-extension-os-quota-sets 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 ([https://developer.openstack.org/api-ref/compute/#update-quotas nova-quotas-update]), Neutron ([https://developer.openstack.org/api-ref/networking/v2/?expanded=update-quota-for-a-project-detail#update-quota-for-a-project neutron-quotas-update]) and Cinder ([https://developer.openstack.org/api-ref/block-storage/v3/#update-quotas-for-a-project cinder-quotas-update]) operations. Moreover, default compute quotas can be updated by means of a specific Nova API ([https://developer.openstack.org/api-ref/compute/#create-or-update-quotas-for-quota-class 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 ([https://developer.openstack.org/api-ref/compute/#show-a-quota nova-quotas-query]), Neutron ([https://developer.openstack.org/api-ref/networking/v2/?expanded=list-default-quotas-for-a-project-detail#list-quotas-for-a-project neutron-quotas-query]) and Cinder ([https://developer.openstack.org/api-ref/block-storage/v3/#show-quotas-for-a-project 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, Storage resources 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 ([https://docs.openstack.org/keystone/latest/advanced-topics/event_notifications.html 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 ([https://github.com/openstack/keystone/blob/stable/ocata/keystone/notifications.py 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 ([http://gnocchi.xyz/rest.html#resources 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==~~		= ETSI NFV meets OpenStack workshop materials =
	~~'''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 (~~[~~http~~://~~gnocchi~~.~~xyz~~/~~rest~~.~~html#resources gnocchi-resource-api~~]).		* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]
			* [https://nfvwiki.etsi.org/images/WhyWhatHow-ETSINFV.pdf WhyWhatHow-ETSINFV]
			* [https://nfvwiki.etsi.org/images/OpenStack_ETSI_NFV_workshop.pdf OpenStack_ETSI_NFV_workshop]
			* [https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained ptg-denver-etsi-nfv-tst003-gaps-explained]
			* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]
			* [https://nfvwiki.etsi.org/images/NFV_PoCs_%26_Plugtests.ppt NFV_PoCs_Plugtests]
			* [https://nfvwiki.etsi.org/images/OpenStack_Joint_meeting_TST_v2.pdf OpenStack_Joint_meeting_TST]

Csatarig at 15:14, 15 May 2018

2018-05-15T15:14:37Z

← Older revision		Revision as of 16:14, 15 May 2018
Line 1:		Line 1:
	= Introduction =		== 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).		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.		The following list are the gaps discovered so far.
	~~= Gaps =~~
	==[GAP-01] Affinity resource list scope==		==[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. <br />		'''Description:''' Allocate Virtualised Compute Resource contains AffinityOrAntiAffinityConstraint which offers two alternative ways to define affinity rules: affinityAntiAffinityResourceList and affinityAntiAffinityResourceGroup. <br />
Line 9:		Line 9:

	==[GAP-03] Resource reservation for calendar time==		==[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. <br />		'''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. <br />
	OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].		OPNFV [https://wiki.opnfv.org/display/promise/Promise Promise] plans to cover this functionality by with the usage of [https://wiki.openstack.org/wiki/Blazar Blazar].

Line 16:		Line 16:

	==[GAP-05] Publish subscribe to resource changes==		==[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.		'''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 ==		==[GAP-06] Bandwidth per Network Interface ==
Line 39:		Line 39:

	== [GAP-11] Change Network Forwarding Path (NFP) State operation ==		== [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.<br />		'''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 <br />

			==[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 [https://nfvprivatewiki.etsi.org/index.php?title=GapsAndUserStories#.5BQUOTA-01.5D_Are_infrastructure_resource_group-s_OpenStack_tenants.3F 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 ([https://developer.openstack.org/api-ref/compute/#quota-sets-os-quota-sets nova-quotas]), networking ([https://developer.openstack.org/api-ref/networking/v2/?expanded=#quotas-extension-quotas neutron-quotas]) and storage ([https://developer.openstack.org/api-ref/block-storage/v3/#quota-sets-extension-os-quota-sets 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 ([https://developer.openstack.org/api-ref/compute/#update-quotas nova-quotas-update]), Neutron ([https://developer.openstack.org/api-ref/networking/v2/?expanded=update-quota-for-a-project-detail#update-quota-for-a-project neutron-quotas-update]) and Cinder ([https://developer.openstack.org/api-ref/block-storage/v3/#update-quotas-for-a-project cinder-quotas-update]) operations. Moreover, default compute quotas can be updated by means of a specific Nova API ([https://developer.openstack.org/api-ref/compute/#create-or-update-quotas-for-quota-class 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 ([https://developer.openstack.org/api-ref/compute/#show-a-quota nova-quotas-query]), Neutron ([https://developer.openstack.org/api-ref/networking/v2/?expanded=list-default-quotas-for-a-project-detail#list-quotas-for-a-project neutron-quotas-query]) and Cinder ([https://developer.openstack.org/api-ref/block-storage/v3/#show-quotas-for-a-project 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, Storage resources 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 ([https://docs.openstack.org/keystone/latest/advanced-topics/event_notifications.html 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 ([https://github.com/openstack/keystone/blob/stable/ocata/keystone/notifications.py 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 ([http://gnocchi.xyz/rest.html#resources 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.

	= ~~ETSI NFV meets OpenStack workshop materials~~ =		==[GAP-21] Performance Information Available Notification==
	* [~~https://etherpad.openstack.org/p/etsi~~-~~nfv-openstack-gathering-denver etherpad~~]		'''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 ([http://gnocchi.xyz/rest.html#resources gnocchi-resource-api]).
	* [https:~~//nfvwiki~~.~~etsi~~.~~org/images/WhyWhatHow-ETSINFV~~.~~pdf WhyWhatHow-ETSINFV]~~
	* [https://nfvwiki.~~etsi~~.~~org/images/OpenStack_ETSI_NFV_workshop~~.~~pdf OpenStack_ETSI_NFV_workshop]~~
	* [~~https~~://~~etherpad~~.~~openstack~~.~~org/p/ptg-denver-etsi~~-~~nfv~~-~~tst003-gaps-explained ptg-denver-etsi-nfv-tst003-gaps-explained]~~
	* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]
	* [https://nfvwiki.etsi.org/images/NFV_PoCs_%26_Plugtests.ppt NFV_PoCs_Plugtests]
	* [https://nfvwiki.etsi.~~org/images/OpenStack_Joint_meeting_TST_v2.pdf OpenStack_Joint_meeting_TST]~~

Csatarig: /* ETSI NFV meets OpenStack workshop materials */

2017-09-13T15:12:38Z

ETSI NFV meets OpenStack workshop materials

← Older revision		Revision as of 16:12, 13 September 2017
Line 47:		Line 47:
	* [https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained ptg-denver-etsi-nfv-tst003-gaps-explained]		* [https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained ptg-denver-etsi-nfv-tst003-gaps-explained]
	* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]		* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]
	* [https://nfvwiki.etsi.org/images/NFV_PoCs_%26_Plugtests.ppt ~~NFV_PoCs_%26_Plugtests~~]		* [https://nfvwiki.etsi.org/images/NFV_PoCs_%26_Plugtests.ppt NFV_PoCs_Plugtests]
	* [https://nfvwiki.etsi.org/images/OpenStack_Joint_meeting_TST_v2.pdf OpenStack_Joint_meeting_TST]		* [https://nfvwiki.etsi.org/images/OpenStack_Joint_meeting_TST_v2.pdf OpenStack_Joint_meeting_TST]

Csatarig: /* ETSI NFV meets OpenStack workshop materials */

2017-09-13T15:11:49Z

ETSI NFV meets OpenStack workshop materials

← Older revision		Revision as of 16:11, 13 September 2017
Line 44:		Line 44:
	* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]		* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]
	* [https://nfvwiki.etsi.org/images/WhyWhatHow-ETSINFV.pdf WhyWhatHow-ETSINFV]		* [https://nfvwiki.etsi.org/images/WhyWhatHow-ETSINFV.pdf WhyWhatHow-ETSINFV]
			* [https://nfvwiki.etsi.org/images/OpenStack_ETSI_NFV_workshop.pdf OpenStack_ETSI_NFV_workshop]
			* [https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained ptg-denver-etsi-nfv-tst003-gaps-explained]
	* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]		* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]
			* [https://nfvwiki.etsi.org/images/NFV_PoCs_%26_Plugtests.ppt NFV_PoCs_%26_Plugtests]
			* [https://nfvwiki.etsi.org/images/OpenStack_Joint_meeting_TST_v2.pdf OpenStack_Joint_meeting_TST]

Csatarig at 15:03, 13 September 2017

2017-09-13T15:03:36Z

← Older revision		Revision as of 16:03, 13 September 2017
Line 43:		Line 43:
	= ETSI NFV meets OpenStack workshop materials =		= ETSI NFV meets OpenStack workshop materials =
	* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]		* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]
			* [https://nfvwiki.etsi.org/images/WhyWhatHow-ETSINFV.pdf WhyWhatHow-ETSINFV]
	* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]		* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]

Csatarig: /* ETSI NFV meets OpenStack workshop materials */

2017-09-13T14:58:34Z

ETSI NFV meets OpenStack workshop materials

← Older revision		Revision as of 15:58, 13 September 2017
Line 43:		Line 43:
	= ETSI NFV meets OpenStack workshop materials =		= ETSI NFV meets OpenStack workshop materials =
	* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]		* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]

			* [https://docs.google.com/presentation/d/1lbhndc5WqG9EmwgAv8ajfLORWLhOrvGzuZNQB5s3afM/edit#slide=id.g268fbe379d_0_0 Glare]

Csatarig at 14:56, 13 September 2017

2017-09-13T14:56:31Z

← Older revision		Revision as of 15:56, 13 September 2017
Line 42:		Line 42:

	= ETSI NFV meets OpenStack workshop materials =		= ETSI NFV meets OpenStack workshop materials =
	* ~~[[etherpad]~~ [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver]]		* [https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver etherpad]