Differences

This shows you the differences between two versions of the page.

--- doctor:architecture [2015/02/02 07:05]
Ryota Mibu created
+++ doctor:architecture [2015/07/01 08:36] (current)
Ryota Mibu
@@ Line 1: / Line 1: @@
 ===== Doctor Architecture =====
-The point is taking mechanism of registering subscribe method for notifications which is the same approach of Ceilometer, and designing architecture for immediate notification and pluggable driver model for various type of resource and events.
+NOTE: This page is abandoned, see latest document http://artifacts.opnfv.org/doctor/html/03-architecture.html .
-==== Functional block ====
-{{ :doctor_arch.png |}}
-Inspector has ability to receive various failure notifications regarding physical resource from monitor(s), find affected referring resource map from physical to virtual, and update state of virtual resource (and physical resource). Inspector has drivers for different types of events and resources.
-The reason for separation of Inspector and Controller is to make Controller focus on simple operation by avoiding tight integration of various health check mechanisms.
-Controller has responsibility for resource map, ability to accept update request for resource state (exposing as provider API) and notifies all events regarding virtual resources to Notifier. Optionally, Controller has ability to poison state of virtual resources when received failure of mapped physical resource by Inspector.
-Controller also calculates capability of Resource Pool one failure of physical resource received and notifies the update as event to Notifier.
-Controller(s) might be Nova, Neutron and Cinder in OpenStack.
-Notifier has ability to register alarm regarding virtual resource with subscribe method such as API endpoint of User-side Manager, and to notify alarm configuration when received events from Controller(s). Notifier looks like Ceilometer but focused on immediate notification with simple filtering.
-==== Initial Implementation ====
-{{ :doctor_impl.png |}}
-Implementation should be done in OpenStack which is prominent candidate for VIM.
-Inspector shall be developed with driver mechanism. Interface to receive failure from Monitor(s) is TBD (REST?).
-Controller will be performed by Nova with additional implementation of provider API (REST) to update resource state.
-Notifier will be developed based on Ceilometer. Notifications from Controller (Nova) are passed through message queuing system in channel like audit. Initial subscriber method shall be REST and/then(?) develop dedicated websocket linked between Notifier and User-side Manager.
-Here is proposal to implement outside of Nova: {{:doctor-opnfv-proposal.pptx|}}
-==== Alternative ====
-There is alternative implementation which individual controller has own notifier in the common manner. This means Nova, Neutron and Cinder to have alarm conf tables in its DB and functions for receive, filter and send notifications. This could be done in one of them, then apply others. This approach will be very hard to merge our code by upstream community in such difficult situation to put in new features, especially Nova.
-==== Interface ====
-  * Interface of VIM to receive notifications (Inspector – Controller?)
-  * Interface of VIM to send notifications (Notifier – User-side Manager)
-Note: Specification of these interfaces will be done in phase 2 (Collaborative Development).
-Some more details on project description could be found [[:requirements_projects:doctor_fault_mangement_and_maintenance|here]].
-{{:etsi_fault_relation_ak_tl.pdf|Relevance with ETSI NFV E2E Arch.}}

Wiki

User Tools

Site Tools

Differences

Page Tools