Clairify notification related architecture

This patch is based on the related unresolved comment in
https://gerrit.opnfv.org/gerrit/#/c/304

JIRA: DOCTOR-4

Signed-off-by: Balazs Gibizer <balazs.gibizer@ericsson.com>
Change-Id: I2cc90e0df808d5aa39fa278405327952c368baa9

diff --git a/requirements/03-architecture.rst b/requirements/03-architecture.rst
index fee136d..26c864a 100644 (file)
--- a/requirements/03-architecture.rst
+++ b/requirements/03-architecture.rst
@@ -157,15 +157,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.
 
 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
+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.
 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
 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.

 
 Recovery Action
 ^^^^^^^^^^^^^^^
 
 Recovery Action
 ^^^^^^^^^^^^^^^