* A reservation request for future use may cancel another, not yet started,
reservation with lower priority
- * An allocation request without reservations and time-unbound may be granted
- resources and prevent a future reservation with lower priority from getting
- resources at start time
+ * An allocation request without reservations and time-unbound [#unbound]_ may
+ be granted resources and prevent a future reservation with lower priority
+ from getting resources at start time
* A reservation request may result in terminating resources allocated to a
request with no reservation, if the latter has lower priority
+
+.. [#unbound] In this case, the consumer (VNFM or NFVO) requests to immediately
+ instantiate and assign virtualized resources without having
+ reserved the resources beforehand
====== ========== ==========================================================
Flavor Identifier Identifier that is passed in the request to obtain
information of the number of virtual resources that can be
- instantiated according to this flavour with the available
+ instantiated according to this flavor with the available
capacity
====== ========== ==========================================================
End Timestamp End time for consumption of the reserved resources
Expiry Timestamp If not all reserved resources are allocated between start
time and expiry, the VIM shall release the corresponding
- resources
+ resources [#expiry]_
Amount Number Amount of the resources per resource item type (i.e.
compute/network/storage) that need to be reserved
Zone Identifier The zone where the resources need(s) to be reserved
physical machines, etc.)
========== ========== =========================================================
+.. [#expiry] Expiry is a period around start time within which, the allocation
+ process must take place. If allocation process does not start
+ within the expiry period, the reservation becomes invalid and VIM
+ should release the resources
+
Create Resource Reservation Reply
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section provides a list of gaps in upstream projects for realizing
resource reservation and management. The gap analysis work focuses on the
-current OpenStack Blazar project [2]_ in this first release.
+current OpenStack Blazar project [2] in this first release.
-OpenStack Blazar
-================
+OpenStack
+=========
Resource reservation for future use
-----------------------------------
Stormify
^^^^^^^^
* Stormify enables rapid web applications construction
-* Based on Emberjs style Data stores
-* Developed on Nodejs using coffeescript/javascript
+* Based on Ember.js style Data stores
+* Developed on Node.js using coffeescript/javascript
* Auto RESTful API generation based on Data Models
* Development starts with defining Data Models
* Code hosted at github : http://github.com/stormstack/stormify
* Data Model driven management of Resource Providers
* Based on Stormify Framework and implemented as per the OPNFV Promise
requirements
-* Data Models are auto generated and RESTFul API code from YANG schema
+* Data Models are auto generated and RESTful API code from YANG schema
* Currently planned key services include Resource Capacity Management Service
and Resource Reservation Service
* List of YANG schemas for Promise project is attached in the Appendix
* Description
* To-be: To be able to discover resources in real time from OpenStack
- components. Planning to add OpenStack Project to interface with promise for
+ components. Planning to add OpenStack Project to interface with Promise for
real time updates on capacity or any failures
* As-is: Currently, resource capacity is learnt using NB APIs related to
quota
* Related Blueprints: N/A
-
-
-.. [2] OpenStack Blazar Project, [Online]. Available at
- https://wiki.openstack.org/wiki/Blazar
* Thresholds [0..N]: Lower/Upper limits for triggering change event for
used/reserved/total capacity change for specified resource items
* NotificationId [0..1]: Identification of existing capacity change event
- notification issued by the VIM. When specified. The previously defined
- conditions for change event notifications wil be re-used and notification
+ notification issued by the VIM. When specified, the previously defined
+ conditions for change event notifications will be re-used and notification
sent to the additional requestor.
Application/json::
Reply Parameters:
-* subscriptionId (Identifier): Identification of the capacity change event
- notification issued by the VIM.
+* subscriptionId (Identifier): Identification of the created subscription to
+ receive notifications about capacity change events
* created (DateTime): Timestamp when subscription has been created
-* m essage [0..1] (String): Output message that provides additional information
+* message [0..1] (String): Output message that provides additional information
about the subscribe request
Application/json::
{
"created": "2015-03-23T00:00:01Z",
- "notificationId": "abcdef-ghijkl-123456789"
+ "subscriptionId": "abcdef-ghijkl-123456789"
}
Query Resource Capacity
@startuml
class CreateResourceReservationRequest {
- + start [0..1]: DateTime
- + end [0..1]: DateTime
+ + startTime [0..1]: DateTime
+ + endTime [0..1]: DateTime
+ expiry [0..1]: DateTime
+ virtualizationContainerReservation [0..N]: VirtualizationContainerReservationClass
+ computePoolReservation [0..1]: ComputePoolReservationClass
+ storagePoolReserved [0..1]: StoragePoolReservedClass
+ networkReserved [0..1]: NetworkReservedClass
+ reservationStatus [1]: String
- + startTime [0..1]: Time
- + endTime [0..1]: Time
+ + startTime [0..1]: DateTime
+ + endTime [0..1]: DateTime
+ message [0..1]: String
}
.. glossary::
+ Administrator
+ Administrator of the system, e.g. OAM in Telco context.
+
+ Consumer
+ User-side Manager; consumer of the interfaces produced by the VIM; VNFM,
+ NFVO, or Orchestrator in ETSI NFV [7] terminology.
+
NFV
Network Function Virtualization
and software components which build up the environment in which VNFs are
deployed.
- VNF
- Virtualized Network Function. Implementation of an Network Function that
- can be deployed on a Network Function Virtualization Infrastructure (NFVI).
-
- VIM
- Virtualized Infrastructure Manager; functional block that is responsible
- for controlling and managing the NFVI compute, storage and network
- resources, usually within one operator's Infrastructure Domain, e.g. NFVI
- Point of Presence (NFVI-PoP).
-
NFVO
Network Functions Virtualization Orchestrator; functional block that
manages the Network Service (NS) lifecycle and coordinates the management
(supported by the VIM) to ensure an optimized allocation of the necessary
resources and connectivity.
- VNFM
- Virtualized Network Function Manager; functional block that is responsible
- for the lifecycle management of VNF.
-
- Consumer
- User-side Manager; consumer of the interfaces produced by the VIM; VNFM,
- NFVO, or Orchestrator in ETSI NFV [7] terminology.
+ Physical resource
+ Actual resources in NFVI; not visible to Consumer.
- Administrator
- Administrator of the system, e.g. OAM in Telco context.
+ VIM
+ Virtualized Infrastructure Manager; functional block that is responsible
+ for controlling and managing the NFVI compute, storage and network
+ resources, usually within one operator's Infrastructure Domain, e.g. NFVI
+ Point of Presence (NFVI-PoP).
Virtual Machine (VM)
Virtualized computation environment that behaves very much like a physical
computer/server.
- Virtual Storage
- Virtualized non-volatile storage allocated to a VM.
-
Virtual network
Virtual network routes information among the network interfaces of VM
instances and physical network interfaces, providing the necessary
connectivity.
- Physical resource
- Actual resources in NFVI; not visible to Consumer.
-
Virtual resource
A Virtual Machine (VM), a virtual network, or virtualized storage; Offered
resources to "Consumer" as result of infrastructure virtualization; visible
to Consumer.
+
+ Virtual Storage
+ Virtualized non-volatile storage allocated to a VM.
+
+ VNF
+ Virtualized Network Function. Implementation of an Network Function that
+ can be deployed on a Network Function Virtualization Infrastructure (NFVI).
+
+ VNFM
+ Virtualized Network Function Manager; functional block that is responsible
+ for the lifecycle management of VNF.
:Authors: Ravi Chunduru (ClearPath Networks), Peter Lee (ClearPath Networks),
Gerald Kunzmann (NTT DOCOMO), Ryota Mibu (NEC),
Carlos Goncalves (NEC), Arturo Martin De Nicolas (Ericsson)
-:Project creation date: 2014-12-04
-:Submission date: 2015-04-XX
+
+:History:
+ ========== =====================================================
+ Date Description
+ ========== =====================================================
+ 04.12.2014 Project creation
+ 20.04.2015 Initial version of the deliverable uploaded to gerrit
+ 19.06.2015 Stable version of the Promise deliverable
+ ========== =====================================================
:Abstract: Promise is an OPNFV requirement project. Its objective is to realize
ETSI NFV defined resource reservation and NFVI capacity features
Code Review / promise.git / commitdiff