docs/requirements/impl_architecture.rst

   1 Detailed architecture and message flows
   2 =======================================
   3
   4 Within the Promise project we consider two different architectural options,
   5 i.e. a *shim-layer* based architecture and an architecture targeting at full
   6 OpenStack *integration*.
   7
   8 Shim-layer architecture
   9 -----------------------
  10
  11 The *shim-layer architecture* is using a layer on top of OpenStack to provide
  12 the capacity management, resource reservation, and resource allocation
  13 features.
  14
  15
  16 Detailed Message Flows
  17 ^^^^^^^^^^^^^^^^^^^^^^
  18
  19 .. note:: This section has to be updated.
  20
  21 Resource Capacity Management
  22 """"""""""""""""""""""""""""
  23
  24 .. figure:: images/figure5.png
  25     :name: figure5
  26     :width: 90%
  27
  28     Capacity Management Scenario
  29
  30 :numref:`figure5` shows a detailed message flow between the consumers and the
  31 functional blocks inside the VIM and has the following steps:
  32
  33 Step 1: The consumer subscribes to capacity change notifications
  34
  35 Step 2: The Capacity Manager monitors the capacity information for the various
  36 types of resources by querying the various Controllers (e.g. Nova, Neutron,
  37 Cinder), either periodically or on demand and updates capacity information in
  38 the Capacity Map
  39
  40 Step 3: Capacity changes are notified to the consumer
  41
  42 Step 4: The consumer queries the Capacity Manager to retrieve capacity detailed
  43 information
  44
  45 Resource Reservation
  46 """"""""""""""""""""
  47
  48 .. figure:: images/figure6.png
  49     :name: figure6
  50     :width: 90%
  51
  52     Resource Reservation for Future Use Scenario
  53
  54 :numref:`figure6` shows a detailed message flow between the consumers and the
  55 functional blocks inside the VIM and has the following steps:
  56
  57 Step 1: The consumer creates a resource reservation request for future use by
  58 setting a start and end time for the allocation
  59
  60 Step 2: The consumer gets an immediate reply with a reservation status message
  61 "reservationStatus" and an identifier to be used with this reservation instance
  62 "reservationID"
  63
  64 Step 3: The consumer subscribes to reservation notification events
  65
  66 Step 4: The Resource Reservation Manager checks the feasibility of the
  67 reservation request by consulting the Capacity Manager
  68
  69 Step 5: The Resource Reservation Manager reserves the resources and stores the
  70 list of reservations IDs generated by the Controllers (e.g. Nova, Neutron,
  71 Cinder) in the Reservation Map
  72
  73 Step 6: Once the reservation process is completed, the VIM sends a notification
  74 message to the consumer with information on the reserved resources
  75
  76 Step 7: When start time arrives, the consumer creates a resource allocation
  77 request.
  78
  79 Step 8: The consumer gets an immediate reply with an allocation status message
  80 "allocationStatus".
  81
  82 Step 9: The consumer subscribes to allocation notification events
  83
  84 Step 10: The Resource Allocation Manager allocates the reserved resources. If
  85 not all reserved resources are allocated before expiry, the reserved resources
  86 are released and a notification is sent to the consumer
  87
  88 Step 11: Once the allocation process is completed, the VIM sends a notification
  89 message to the consumer with information on the allocated resources
  90
  91
  92 Integrated architecture
  93 -----------------------
  94
  95 The *integrated architecture* aims at full integration with OpenStack.
  96
  97 Detailed Message Flows
  98 ^^^^^^^^^^^^^^^^^^^^^^
  99
 100 .. note:: to be done
 101
 102 Resource Reservation
 103 """"""""""""""""""""
 104
 105 .. note:: to be specified