+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
Detailed architecture and interface specification
=================================================
affected resources, for example migrate/update/terminate specific
resource(s). After reception of such instructions, the VIM is executing the
requested action, e.g. it will migrate or terminate a virtual resource.
-
- a. Query request from Consumer to VIM to get information about the current
+a. Query request from Consumer to VIM to get information about the current
status of a resource.
- b. Response to the query request with information about the current status of
+b. Response to the query request with information about the current status of
the queried resource. In case the resource is in "fault" state, information
about the related fault(s) is returned.
NFVI Maintenance
^^^^^^^^^^^^^^^^
+.. figure:: images/figure9.png
+ :name: figure9
+ :width: 100%
+
+ NFVI maintenance work flow
The detailed work flow for NFVI maintenance is shown in :numref:`figure9`
and has the following steps. Note that steps 1, 2, and 5 to 8a in the NFVI
6. Maintenance notification to Consumer.
7. The Consumer switches to standby configuration (STBY)
8. Instructions from Consumer to VIM requesting certain recovery actions to be
- performed (step 7a). After reception of such instructions, the VIM is
+ performed (step 8a). After reception of such instructions, the VIM is
executing the requested action in order to empty the physical resources (step
- 7b).
+ 8b).
9. Maintenance response from VIM to inform the Administrator that the physical
machines have been emptied (or the operation resulted in an error state).
10. Administrator is coordinating and executing the maintenance operation/work
on the NFVI.
-
- A) Query request from Administrator to VIM to get information about the
- current state of a resource.
- B) Response to the query request with information about the current state of
- the queried resource(s). In case the resource is in "maintenance" state,
- information about the related maintenance operation is returned.
-
-.. figure:: images/figure9.png
- :name: figure9
- :width: 100%
-
- NFVI maintenance work flow
+a) Query request from Administrator to VIM to get information about the
+ current state of a resource.
+b) Response to the query request with information about the current state of
+ the queried resource(s). In case the resource is in "maintenance" state,
+ information about the related maintenance operation is returned.
.. figure:: images/figure10.png
:name: figure10
NFVI Maintenance implementation plan
-:numref:`figure10` shows a more detailed message flow (Steps 4 to 6)
+:numref:`figure10` shows a more detailed message flow (Steps 3 to 6 and 9)
between the 4 building blocks introduced in Section 5.1..
3. The Administrator is sending a StateChange request to the Controller residing
Simple information elements:
-* SubscriptionID: identifies a subscription to receive fault or maintenance
+* SubscriptionID (Identifier): identifies a subscription to receive fault or maintenance
notifications.
-* NotificationID: identifies a fault or maintenance notification.
+* NotificationID (Identifier): identifies a fault or maintenance notification.
* VirtualResourceID (Identifier): identifies a virtual resource affected by a
fault or a maintenance action of the underlying physical resource.
* PhysicalResourceID (Identifier): identifies a physical resource affected by a
* EventTime (Datetime): Time when the fault was observed.
* EventStartTime and EventEndTime (Datetime): Datetime range that can be used in
a FaultQueryFilter to narrow down the faults to be queried.
-* ProbableCause: information about the probable cause of the fault.
+* ProbableCause (String): information about the probable cause of the fault.
* CorrelatedFaultID (Integer): list of other faults correlated to this fault.
* isRootCause (Boolean): Parameter indicating if this fault is the root for
other correlated faults. If TRUE, then the faults listed in the parameter
* ZoneID (Identifier): Identifier of the resource zone. A resource zone is the
logical separation of physical and software resources in an NFVI deployment
for physical isolation, redundancy, or administrative designation.
-* Metadata (Key-Value-Pairs): provides additional information of a physical
+* Metadata (Key-value pair): provides additional information of a physical
resource in maintenance/error state.
Complex information elements (see also UML diagrams in :numref:`figure13`
particular describing the information elements used for alarm notifications.
- FaultID [1] (Identifier)
- - FaultType [1]
+ - FaultType [1] (String)
- Severity [1] (Integer)
- EventTime [1] (Datetime)
- - ProbableCause [1]
+ - ProbableCause [1] (String)
- CorrelatedFaultID [0..*] (Identifier)
- FaultDetails [0..*] (Key-value pair)
- PhysicalResourceID [1] (Identifier)
- PhysicalResourceState [1] (String): mandates the new state of the physical
resource.
+ - Metadata [0..*] (Key-value pair)
* PhysicalResourceInfoClass:
- FirmwareVersion [0..1] (String)
- HypervisorVersion [0..1] (String)
- ZoneID [0..1] (Identifier)
+ - Metadata [0..*] (Key-value pair)
* StateQueryFilterClass: narrows down a StateQueryRequest, for example it limits
the query to certain physical resources, a certain zone, or a given resource
resources. For each resource, information about the current state, the
firmware version, etc. is provided.
+
+Detailed southbound interface specification
+-------------------------------------------
+
+This section is specifying the southbound interfaces for fault management
+between the Monitors and the Inspector.
+Although southbound interfaces should be flexible to handle various events from
+different types of Monitors, we define unified event API in order to improve
+interoperability between the Monitors and the Inspector.
+This is not limiting implementation of Monitor and Inspector as these could be
+extended in order to support failures from intelligent inspection like prediction.
+
+Note: The interface definition will be aligned with current work in ETSI NFV IFA
+working group.
+
+Fault event interface
+^^^^^^^^^^^^^^^^^^^^^
+
+This interface allows the Monitors to notify the Inspector about an event which
+was captured by the Monitor and may effect resources managed in the VIM.
+
+EventNotification
+_________________
+
+
+Event notification including fault description.
+The entity of this notification is event, and not fault or error specifically.
+This allows us to use generic event format or framework build out of Doctor project.
+The parameters below shall be mandatory, but keys in 'Details' can be optional.
+
+Parameters:
+
+* Time [1]: Datetime when the fault was observed in the Monitor.
+* Type [1]: Type of event that will be used to process correlation in Inspector.
+* Details [0..1]: Details containing additional information with Key-value pair style.
+ Keys shall be defined depending on the Type of the event.
+
+E.g.:
+
+.. code-block:: bash
+
+ {
+ 'event': {
+ 'time': '2016-04-12T08:00:00',
+ 'type': 'compute.host.down',
+ 'details': {
+ 'hostname': 'compute-1',
+ 'source': 'sample_monitor',
+ 'cause': 'link-down',
+ 'severity': 'critical',
+ 'status': 'down',
+ 'monitor_id': 'monitor-1',
+ 'monitor_event_id': '123',
+ }
+ }
+ }
+
+Optional parameters in 'Details':
+
+* Hostname: the hostname on which the event occurred.
+* Source: the display name of reporter of this event. This is not limited to monitor, other entity can be specified such as 'KVM'.
+* Cause: description of the cause of this event which could be different from the type of this event.
+* Severity: the severity of this event set by the monitor.
+* Status: the status of target object in which error occurred.
+* MonitorID: the ID of the monitor sending this event.
+* MonitorEventID: the ID of the event in the monitor. This can be used by operator while tracking the monitor log.
+* RelatedTo: the array of IDs which related to this event.
+
+Also, we can have bulk API to receive multiple events in a single HTTP POST
+message by using the 'events' wrapper as follows:
+
+.. code-block:: bash
+
+ {
+ 'events': [
+ 'event': {
+ 'time': '2016-04-12T08:00:00',
+ 'type': 'compute.host.down',
+ 'details': {},
+ },
+ 'event': {
+ 'time': '2016-04-12T08:00:00',
+ 'type': 'compute.host.nic.error',
+ 'details': {},
+ }
+ ]
+ }
+
+
Blueprints
----------
and service states correctly.
.. [*] https://blueprints.launchpad.net/nova/+spec/pacemaker-servicegroup-driver
-
-..
- vim: set tabstop=4 expandtab textwidth=80:
Code Review / doctor.git / blobdiff