summaryrefslogtreecommitdiffstats
path: root/requirements
diff options
context:
space:
mode:
authorBalazs Gibizer <balazs.gibizer@ericsson.com>2015-06-16 14:58:17 +0200
committerBalazs Gibizer <balazs.gibizer@ericsson.com>2015-07-14 11:06:09 +0200
commitfa7df92983324cd25472857c0575d0224e843bca (patch)
tree5c7ac9dc68522c38f4add42c9d6fa3930cb10dc0 /requirements
parent04b228985c77265970081d6f9e72e5ac1a51fbbf (diff)
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
Diffstat (limited to 'requirements')
-rw-r--r--requirements/03-architecture.rst16
1 files changed, 10 insertions, 6 deletions
diff --git a/requirements/03-architecture.rst b/requirements/03-architecture.rst
index fee136d7..26c864a0 100644
--- 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.
-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.
-
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
^^^^^^^^^^^^^^^