1. Doctor Implementation Plan (Discussion) Feb. 6, 2015 Ryota Mibu, Tomi Juvonen, Gerald Kunzmann, Carlos Goncalves

2. Contents Functional Block (Architecture) –Type A: VIM does not run any recovery by itself –Type B: some actions done by VIM automatically # describe sequences in user and admin perspective Implementation Plan NOTE: Agreement were described followed by ”  ”.

3. Functional Block (Architecture) Discussion Points –Should we consider auto recovery function in VIM? Leave it as option and future development?  Write this option in requirement document, but not implement in our first step.  We need actions by some manager outside of VIM. (Actions that requires admin right should be clarify in the document.) –Can we avoid duplication of data source particularly the resource map and state DB?  Yes. (State means state of resource handled in infra, not indicate internal state of VM.) –Can we done all failure selection and aggregation by Inspector?  We can done it by using Zabbix, but we have to consider replacement Zabbix by other tools to achieve framework which has modularity that means each module is pluggable and replaceable. This idea is important in OPNFV as well as OpenStack.  TODO(Ryota): Study Zabbix aggregation framework, and rethink functional block including Monitor, Inspector and Predictor. Also check “KIE”.  We will check other related projects. Other projects (HA for VNF, Failure Prediction) seems to be working on similar issue. (Failure Prediction team focus on finding warning rather than notify error immediately.)

4. Functional Block: Type A (User) Notifier User-side Manager NFVI Monitor Alarm conf 0. Set Alarm on VM 3. Update State 2. Find Affected 5. Notify VM error VNFs Controller Resource Map 1. Receive Failure Inspector 4. Notify all 6-2. Action 4. (alt) Notify 6-1. Action Failure Policy

5. Functional Block: Type A (Admin) Notifier User-side Manager NFVI Monitor Alarm conf 0. Set Alarm on Host 3. Update State 2. Find Affected VNFs Controller Resource Map 1. Receive Failure Inspector 4. Notify all 4. (alt) Notify Admin-side Manager 5. Notify PM error 6. Deactivate Host6. Shutdown Host Failure Policy

6. Functional Block: Type B (User) Notifier User-side Manager NFVI Monitor Alarm conf 0. Set Alarm on VM (+ recovery action) 3. Update State 2. Find Affected VNFs Controller Resource Map 1. Receive Failure Inspector 4. Notify all 6-2. Action 4. (alt) Notify 6-1. Action 5. Notify VM error Mender Failure Policy

7. Functional Block: Type B (Admin) Notifier User-side Manager NFVI Monitor Alarm conf 0. Set Alarm on Host (+ recovery action) 3. Update State 2. Find Affected VNFs Controller Resource Map 1. Receive Failure Inspector 4. Notify all 4. (alt) Notify Admin-side Manager 5. Notify PM error 6. Deactivate Host 6. Shutdown Host Mender Failure Policy

8. Implementation Plan Discussion Points –How we kept configuration of alarm and reaction passed by user/admin? Not all virtual resource controller (such as Nova, Neutron) have metadata on each resource.  Having own DB. –Which part of functional block can be covered by Zabbix and its plugin script? Anyhow, we should use python, so that we can migrate scripts to some other OpenStack component easier.  Plan A1  Python!

9. Implementation Plan A1 Notifier User-side Manager NFVI Monitor Alarm conf 0. Set Alarm on VM 3. Update State 2. Find Affected 5. Notify VM error VNFs Nova Resource Map 1. Receive Failure Inspector 4. Notify all 6-2. Action 4. (alt) Notify 6-1. Action Failure Policy Zabbix Configuration Queue

10. Implementation Plan A2 Notifier User-side Manager NFVI Monitor Alarm conf 0. Set Alarm on VM 3. Update State 2. Find Affected 5. Notify VM error VNFs Nova Resource Map 1. Receive Failure Inspector 4. Notify all 6-2. Action 4. (alt) Notify 6-1. Action API service Failure Policy Zabbix Configuration

11. OpenStack Summit Vancouver Session? –Design Session (Maybe session planning will be had in April) –General Session (CFS deadline Feb 9 th ) Contents? –Describe Concept –As Doctor project –How OpenStack help (e.g. How to reaction or fencing) Deliverables? –Doc Links –https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Opshttps://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Ops –https://etherpad.openstack.org/p/kilo-summit-ops-monitoringhttps://etherpad.openstack.org/p/kilo-summit-ops-monitoring  Let’s talk at the next meeting (Feb 10).