Merge "Clarifying fault propagation between phys-virtual"
[doctor.git] / requirements / 03-architecture.rst
index 984f254..2f9d24b 100644 (file)
@@ -128,9 +128,12 @@ affected by failures on the physical resources under them. Unavailability of a
 virtualized resource is determined by referring to the mapping of physical and
 virtualized resources.
 
-The relation from physical resources to virtualized resources shall be
-configurable, as the cause of unavailability of virtualized resources can be
-different in technologies and policies of deployment.
+VIM shall allow configuration of fault correlation between physical and
+virtual resources. VIM shall support correlating faults:
+
+* between a physical resource and another physical resource
+* between a physical resource and a virtual resource
+* between a virtual resource and another virtual resource
 
 Failure aggregation is also required in this feature, e.g., a user may request
 to be only notified if failures on more than two standby VMs in an (N+M)
@@ -158,15 +161,19 @@ would lead to heavy signaling traffic. Thus, a publication/subscription
 messaging model is better suited for these notifications, as notifications are
 only sent to subscribed consumers.
 
-Note: the VIM should only accept individual notification URLs for each resource
-by its owner or administrator.
+Notifications will be send out along with the configuration by the consumer.
+The configuration includes endpoint(s) in which the consumers can specify
+multiple targets for the notification subscription, so that various and
+multiple receiver functions can consume the notification message.
+Also, the conditions for notifications shall be configurable, such that
+the consumer can set according policies, e.g. whether it wants to receive
+fault notifications or not.
 
+Note: the VIM should only accept notification subscriptions for each resource
+by its owner or administrator.
 Notifications to the Consumer about the unavailability of virtualized
 resources will include a description of the fault, preferably with sufficient
-abstraction rather than detailed physical fault information. Flexibility in
-notifications is important. For example, the receiver function in the
-consumer-side implementation could have different schema, location, and policies
-(e.g. receive or not, aggregate events with the same cause, etc.).
+abstraction rather than detailed physical fault information.
 
 .. _fencing:
 
@@ -185,9 +192,9 @@ https://wiki.openstack.org/wiki/Fencing_Instances_of_an_Unreachable_Host .
 Recovery Action
 ^^^^^^^^^^^^^^^
 
-In the basic "Fault management using ACT-STBY configuration" use case, no
-automatic actions will be taken by the VIM, but all recovery actions executed by
-the VIM and the NFVI will be instructed and coordinated by the Consumer.
+In the basic :ref:`uc-fault1` use case, no automatic actions will be taken by
+the VIM, but all recovery actions executed by the VIM and the NFVI will be
+instructed and coordinated by the Consumer.
 
 In a more advanced use case, the VIM shall be able to recover the failed virtual
 resources according to a pre-defined behavior for that resource. In principle