From: Ryota Mibu Date: Wed, 15 Jul 2015 06:58:54 +0000 (+0000) Subject: Merge "Clairify notification related architecture" X-Git-Tag: brahmaputra.1.0~32 X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?p=doctor.git;a=commitdiff_plain;h=0188ba46367f6670b32cf01637ce1966a4a842de Merge "Clairify notification related architecture" --- 0188ba46367f6670b32cf01637ce1966a4a842de diff --cc requirements/03-architecture.rst index 82a13f06,26c864a0..1b05935b --- a/requirements/03-architecture.rst +++ b/requirements/03-architecture.rst @@@ -158,30 -157,20 +158,34 @@@ would lead to heavy signaling traffic. 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. +.. _fencing: + +Fencing +^^^^^^^ +Recovery actions, e.g. safe VM evacuation, have to be preceded by fencing the +failed host. Fencing hereby means to isolate or shut down a faulty resource. +Without fencing -- when the perceived disconnection is due to some transient +or partial failure -- the evacuation might lead into two identical instances +running together and having a dangerous conflict. + +There is a cross-project effort in OpenStack ongoing to implement fencing. A +general description of fencing in OpenStack is available here: +https://wiki.openstack.org/wiki/Fencing_Instances_of_an_Unreachable_Host . + Recovery Action ^^^^^^^^^^^^^^^