Wiki

User Tools

Site Tools

Trace:
doctor:meetings

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
doctor:meetings [2015/03/12 14:24]
Ryota Mibu 		doctor:meetings [2015/09/19 13:36]
Ryota Mibu
Line 1: Line 1:
 ====== Doctor Team Meetings ====== ====== Doctor Team Meetings ======
  
-See [[/​meetings/​|https://​wiki.opnfv.org/​meetings/​]] . +This page has been deleted, see new page [[meetings:​doctor|meetings/​doctor]] ​.
- +
-Agenda of the next meeting and latest meeting minutes: https://​etherpad.opnfv.org/​p/​doctor_meetings +
- +
----- +
- +
-==== March 5, 2015 ==== +
- +
-30min +
- +
-Agenda: +
- +
-  * Status of requirement deliverable (Gerald) +
-    * https://​wiki.opnfv.org/​_media/​doctor/​opnfv_doctor_d1_doctor_fault_management_and_maintenance_draft_r9.docx +
-  * Status of BPs (Tomi, Ryota) +
-    * https://​wiki.opnfv.org/​_media/​opnfv-doctor-nova-blueprint.pptx +
-    * https://​wiki.opnfv.org/​_media/​doctor/​opnfv_ceilometer_bp_alignment.20150306.pptx +
- +
-Minutes: +
- +
-  * Status of Document +
-    * 3.1 there is unclaified maintenance usacese --> Tommy will send ETSI Doc Ph2 to us +
-    * 3.1.2 text is missing --> Gerald can add text +
-    * 3.5  +
-    * 4 Gap analysis: are there anyrelated BPs that should be added as references? --> BP links should be added +
-      * Carlos will help check if there are blueprints already filled in and add to the document +
-    * 5 Detailed implementation plan --> all, please check this chapter +
-    * Fig.9 what is maintenance sequence loke like? --> TBD (tentative FB and sequence are proposed) +
-    * Schedule +
-      * 1week for Doctor internal review (-3/17) +
-      * 2 week for OPNFV community review (-3/31) +
-      * 2 week for Doctor for team work (-4/14) +
-      * (OPNFV release 1 4/23) +
-  * Status of BPs: not handled +
- +
-==== March 5, 2015 ==== +
- +
-Ad-hoc meeting for blueprint planning +
- +
-Agenda: +
- +
-  * Discuss BPs +
-  * Report on meeting with HA team +
- +
-Minutes: +
- +
-  * Presentation by Ryota on Ceilometer and where our BPs fit to the Ceilometer architecture (see slides) +
- +
-==== March 3, 2015 ==== +
- +
-Agenda: +
- +
-  * BPs alignment +
-  * Mike from Intel / swfastpathmetric will join this team +
-  * Hijacking the doctor meeting to discuss blue-prints next week for all projects +
-  * Doc status +
- +
-Minutes: +
- +
-  * BPs alignment +
-    * https://​etherpad.opnfv.org/​p/​doctor_bps +
-    * Bring BP topic also to TSC +
-    * BP should have a list of parameters/​data missing +
-    * OpenStack BPs shall be in this format (using OpenStack terminology such that a developer can read/​understand it) +
-    * Proposal to have a high-level description of the BPs in the Wiki +
-    * Ceilometer is the right place to implement such feature, although other alternatives may exist +
-    * TODO(Ryota):​ prepare slides, provide IRC available time +
-  * Hijacking the doctor meeting to discuss blue-prints next week for all projects: +
-    * we should keep 30min for discussing the requirement deliverable +
-  * Doc status: not handled +
- +
-==== Feb 24, 2015 ==== +
- +
-Requirement project round table @ Prague Hackfest +
- +
-Participants:​ Ryota (NEC), Gerald (DOCOMO), Bertrand (DOCOMO), Ashiq (DOCOMO), Tomi (Nokia), Tommy (Ericsson), Carlos (NEC), Gianluca Verin (Athonet) Daniele Munaretto (Athonet), Sharon (ConteXtream),​ Christopher (Dorado Software), Russell (Red Hat), Frank Baudin (Qosmos), Chaoyi (Huawei), Al Morton (AT&T), Xiaolong (Orange), (Oracle), Randy Levensalor (CableLabs) ... +
- +
-Slides can be found here: https://​wiki.opnfv.org/​_media/​doctor/​opnfv_doctor_prague_hackfest_20150224.n.pptx +
- +
-Minutes: +
- +
-  * Use case 1 "Fault management"​ +
-    * Main interest: northbound I/F +
-    * Reaction of VNFM is out of scope +
-    * VM (compute resouces) is the first focus, storage and network resources will follow at later stage +
-  * Fault monitoring: plugable architecture is needed to catch different (critical) faults in NFVI to enable use of different monitoring tools. Predictor (fault prediction) may also be one input. +
-    * see also https://​wiki.opnfv.org/​doctor/​faults +
-  * 4 functional blocks: +
-    * controller (e.g. Nova), monitor (e.g. Nagios, Zabbix), notifier (e.g. re-use Ceilometer),​ inspector (fault aggregation etc) +
-  * VM state in resource map, e.g. "​fault",​ "​recovery",​ "​maintenance"​ (more than just a heartbeat) +
-  * Question of whether other OpenStack components (e.g. Cinder, Glance, etc) can report events/​faults +
-  * What is the timescale to receive such fault notification?​ this would be helpful for the motivation in the blueprints. Telco nodes: i.e. less than 1s, switch to ACT-SBY as soon as possible. +
-  * Preference is event based events, not polling. should be configurable. +
-  * Telco use case would have few hundreds of nodes, not thousands of nodes. +
-  * Demo 1 (using default Ceilometer) takes approximately 65 seconds to notify the fault (90 seconds total including spawning new VM), while demo 2 only takes <= 1 second (26 seconds total) +
-  * Pacemaker is running at application layer; different scope. +
- +
-==== Feb 23, 2015 ==== +
- +
-Doctor/​Fastpathmetrics/​HA Cross Project Meeting @ Prague Hackfest +
- +
-Goal: +
- +
-  * reduce conflicts between requirements projects +
- +
-Minutes: +
- +
-  * Project Intro: +
-    * Doctor: +
-      * detecting fault from resource pool, HW, hypervisor, OS +
-      * table in Openstack mapping between VM and manager +
-    * Fault prediction (Predictor, Requirement project; https://​wiki.opnfv.org/​requirements_projects/​data_collection_of_failure_prediction) +
-      * predict the will be fault in (near) future +
-      * overlap, but not conflict +
-    * FathPathMetrics (Development project; https://​wiki.opnfv.org/​collaborative_development_projects/​opnfv_telco_kpi_monitoring) +
-      * SW fastpath implementation -> interfaces to DPDK +
-      * consume statistics and counters +
-      * information goes to VNF, it does not go to OpenStack (in that sense there is no overlap) +
-    * HA (Requirement project; https://​wiki.opnfv.org/​high_availability_for_opnfv) +
-      * quick response. time-critical. +
-      * very short response for fault detection and resolve +
-      * people from HA project really work on HA today, have a lot of knowledge on it +
-  * Identify Overlap: +
-    * NB I/F +
-      * Doctor is also requiring fast reaction. objective with HA is similar. +
-      * HA has more use cases and may send more information on the northbound I/F. VNFM should be informed about changes. +
-      * Doctor objective is to design a NB I/F. +
-        * Does HA already have flows available?​ +
-        * HA is focusing on application level. Reaction should be as fast as possible. Including the VNFM may slow down the progress. +
-        * In Doctor we will follow the path through VNFM. +
-        * In ETSI we have lifecycle mgmt, where VNFM is responsible for the lifecylce +
-    * There are certain information the VNFM doesn'​t know about. In Doctor we call it "​consumer"​. +
-    * Proposal to do use case analysis for HA. Which use cases may require the VNFM to be involved? "​Doctors"​ will have a look at HA use cases. +
-    * How is the entity to resolve race conditions? Some entity in the "​north"​. +
-    * What about a shared fault collection/​detection entity instead of collecting the same information 3 times? +
-      * Predictor could also notify immediate failures to Doctor. +
-    * Security issues are not addressed in Doctor. Currently assuming a single operator, where policies ensure who can talk to who. +
-    * In Doctor we do not look at application faults, only NFVI faults. +
-    * Huawei: we use Heat to do HA. if one VM died and Heat will find Scaling Group less than 2, it will start a new VM. This may take more than 60s, we need to find something faster for HA. Heat doesn'​t find error in the applications. +
-    * Failure detection time is an issue across all projects. +
-    * Which metrics of fastpath would Doctor be interested in? need to check in detail. Action Item to send metrics to Doctor. +
-    * Hypervisor may detect failure of VM and take action. +
-      * Other failures: VM is using heartbeat. it will e.g. reboot after not receiving a heartbeat for 7s. +
-    * Doctor: if VIM takes action on its own it may conflict the ACT-SBY configuration at the consumer side. this is why the consumer should be involved. +
-    * Which project would address ping-pong issue that may arise? +
-    * We need subscription mechanism including filter (which alarms to be notified about). Mapping VM-PM-VNFM can be recorded during the instantiation. +
-    * Relationship between Doctor and Copper: +
-      * policy defines e.g. when VIM can expose its interface +
-      * When to inform a fault, whom to inform etc is all a kind of policy. +
-      * Copper has both pro-active and reactive deployment of policies. In reactive case, there may be conflict when both Copper and Doctor receive the policies. +
-  * Wrapup: +
-    * Overlap in fault management +
-    * FastPath: monitor traffic metrics; Doctor will need some of the metrics in the VIM. plan to do regular meetings. +
-    * HA: large project with wider scope than Doctor, different use cases. direct flow (to be faster). task to check each others NB I/F in order not to block each other. +
- +
-==== Feb 17, 2015 ==== +
- +
-Agenda: +
- +
-  * Ashiq'​s proposed agenda for the Prague Hackfest next week +
-  * Doctor PoC Demo +
-  * Document Status +
- +
-Minutes: +
- +
-  * Participants:​ Ryota Mibu, Khan Ashiq, Gerald Kunzmann, Carlos Goncalves, Susana, Thinh Nguyenphu, Tommy Lindgren, Bryan Sullivan, Bertrand Souville, Michael Godley, Manuel Rebellon, Uli Kleber +
-  * Hackfest +
-    * https://​etherpad.opnfv.org/​p/​HackfestFeb23 +
-    * Ryota to prepare some slides on what's going to be presented in the demo by end of week +
-      * Carlos will help Ryota +
-    * Requirement projects are scheduled for Tuesday +
-    * Demo: +
-      * OpenStack Controller, Zabbix, 2-3 OpenStack compute servers to launch VMs, client to stress the system, Neutron, Nova, LB as a service, Heat, Ceilometer +
-      * Destroy one of the VM running a WebService +
-      * Key message to OpenStack? Which gap do you want to present? Why use Zabbix instead of Ceilometer (show first gap in our list)? Prepare for such questions. +
-  * Document status +
-    * Gerald to upload current merged draft -> Word version can be found here: https://​wiki.opnfv.org/?​image=doctor%3Aopnfv_doctor_d1_doctor_fault_management_and_maintenance_draft_r2_ak.docx&​ns=doctor&​tab_details=view&​do=media&​tab_files=files +
-    * All links can be found in https://​etherpad.opnfv.org/​p/​doctor +
-    * Urgent work is required on technical sections +
-  * HA and fault prediction project and "​Software FastPath Service Quality Metric"​ project +
-    * Proposal to meet Monday afternoon after BGS project meeting +
-      * Carlos will contact all potential participants +
- +
-==== Feb 10, 2015 ==== +
- +
-Agenda: +
- +
-  * TOC for deliverable:​ https://​etherpad.opnfv.org/​p/​doctor - Gerald +
-  * Implementation Plan quick update - Ryota +
- +
-Minutes: +
- +
-  * OPNFV should be careful with tools projects use and distribute as part of the platform due to their licensing +
-    * E.g. a GPL licensed tool cannot be distributed as part of a commercial OPNFV platform +
-    * OPNFV TSC should discuss this topic and bring awareness to existing and new projects +
-    * http://​lists.opnfv.org/​pipermail/​opnfv-tech-discuss/​2015-February/​001051.html +
-  * Framework should be modular enough to be pluggable with multiple monitoring solutions +
-  * Editors for each first deliverable section were assigned +
-  * Gap analysis to be further extended +
-  * Section editors should have an initial draft ready by Feb 18 +
-  * Deliverable editors (Gerald and Ashiq) will have Feb 19-20 to compile everything together for the Prague Hackfest +
- +
-==== Feb 6, 2015 ==== +
- +
-Extra meeting for Implementation Planning +
- +
-Agenda & Minutes: +
- +
-  * Implementation Planning +
-    * Topic and agreement can be found in {{:​doctor:​doctor.20150206.impl.mtg.pptx|Slides}}. +
- +
-==== Feb 2, 2015 ==== +
- +
-Agenda: +
- +
-  * Timeline - Ryota +
-  * This proposal has close relation: data collection of failure prediction +
-    * https://​wiki.opnfv.org/​requirements_projects/​data_collection_of_failure_prediction +
-    * Both collect host data? +
-    * Doctor to receive faults from predictor. +
-    * Is this feasible. Doctor can be configured to gather also similar data and make graphs. +
-  * Praque meetup time. +
-  * Implementation plan: review comments by Tomi in last week's minutes +
-  * Wiki Updates to follow BGS format - Ryota +
-  * Doctor team participation in the OpenStack Summit Vancouver - Carlos +
-    * Should we aim at proposing a talk session? +
-    * Deadline is February 9 +
-    * http://​www.openstack.org/​summit/​vancouver-2015/​call-for-speakers/​ +
-  * Weekly meeting time - Ryota ? +
-    * There is conflict with ETSI IFA meeting. +
- +
-Minutes: +
- +
-  * Participants:​ Carlos Goncalves, Don Clarke, Ryota Minu, Tomi Juvonen, Yifei Xue, Al Morton, Bertrand Souville, Gerald Kunzmann, Manuel Rebellon, Ojus K. Parikh, Ashiq Khan, Pasi, Paul French, Charlie Hale,  +
-  * Ryota presents a refreshed Timeline +
-    * https://​etherpad.opnfv.org/​p/​doctor +
-    * Initial draft of requirement document should be ready before the Hackfest 23-24 Feb in Prague +
-    * Ashiq asks about task allocation. See:  https://​etherpad.opnfv.org/​p/​doctor +
-    * Target architecture is OpenStack; Implementation plan is on how this will be realized in upstream projects, e.g. interfaces. +
-      * one proposal is using Zabbix. all is already there. +
-  * Predictor project: +
-    * still in proposal phase. we should keep eye on it. it has relation to Doctor +
-  * Implementation plan: +
-    * for evacuation we should stay implementation independent,​ not OpenDayLight or Neutron (they may use it in the actual testbed, but we should restrict Doctor to the interfaces definition) +
-    * it is not intended to use Ceilometer, but a similar service.  +
-      * Agreement to use Zabbix for the GapAnalysis. +
-      * Doctor will have its own RestAPI as wrapper abstracting the in use monitoring solution underneath (e.g. Zabbix) +
-    * it is necessary to be able to isolate a faulty machine, such that new VMs are not started on this machine. +
-    * different ways/​workflows for recovery; we should start by implementing a few sample workflows +
-      * e.g. switch to active hot standby VM, then instantiate a new hot standby instance (this is a Doctor requirement) +
-      * evacuation (if time allows) vs active hot standby (immediate action) +
-      *VNFM is deciding about the best action (this is out of scope of Doctor; Doctor only specifies NB I/F) +
-    * we need to get into more details for this plan. discussion should go via email to make progress before next meeting +
-  * Hackfest +
-    * Take to the hackfest what we have, i.e. if we "​only"​ have one implementation plan so far let's use this. +
-    * https://​etherpad.opnfv.org/​p/​HackfestFeb23 +
-    * Doctor is planned for Tuesday. Also other requirement projects will be discussed on Tuesday. +
-  * Ryota did cleanup of Doctor Wiki page +
-  * Doctor team participation in the OpenStack Summit Vancouver?​ +
-    * related topics.  +
-    * most important blueprints should be ready by May and could be presented there +
-    * Proposal: Talk on a more general topic including Doctor requirements +
-    * Carlos will look into it +
-  * Meeting time -> via email +
- +
-==== Jan 26, 2015 ==== +
- +
-Agenda: +
- +
-  * Discuss maintenance use case - Tommy +
-  * Implementation outside Nova - Tomi +
- +
-Minutes: +
- +
-  * Timeline milestone planning +
-    * Soft schedule for Fault Table, set 1 milestone end of Jan +
-    * Requirement Document should be finished by Mar 15 ? - No +
-      * Ashiq suggested doc should be finished by end of February +
-    * Set some milestone on Hackfest at Prague +
-      * First draft +
-    * TODO(Ryota):​ create wiki page +
-  * Discuss maintenance use case - Tommy +
-    * https://​etherpad.opnfv.org/​p/​doctor_requirement +
-    * Cloud User (NFVO/VNFM) can express allowed operations to VIM by labeling VM some tag e.g. allow-live-migration +
-    * We don't need realtime notification for maintenance +
-  * Implementation outside Nova - Tomi +
-    * https://​wiki.opnfv.org/​_media/​doctor-opnfv-proposal.pptx +
-    * FYI: http://​blog.russellbryant.net/​2014/​10/​15/​openstack-instance-ha-proposal/​ +
-    * Network resources?​ +
-      * Evacuation will move the network also regardless it  being OpenDaylight or Neutron. +
-      * We are trying to tackle step-by-step,​ first focusing on Nova. +
-      * Ceilometer approch seems to be good rather than using metadata on Nova +
-        * What is the relation to Nova metadata? Ceilometer is therrible for FM. It uses polling, and suits for PM. It would be extra step causing delay. It makes a lot of network traffic. Database consumes a lot of memory. +
-    * Should we kick poweroff the host by Doctor? +
-      * One needs to fence host by powering off by shutdown trough OS (or Nova) or if reachable only with IPMI, then trough that. In some case host can be rebooted as recovery, but in most cases it is faulty and needs to be moved to disabled aggrigate or mark for maintenance. If one do not reach host at all, the evacuation trough Nova will anyhow isolate host as everything will be moved to other host (network, disk). +
- +
-==== Jan 19, 2015 ==== +
- +
-Agenda: +
- +
-  * Review of timeline of Doctor project +
-  * List of tasks +
- +
-Minutes: +
- +
-  * Review of timeline of Doctor project +
-    * https://​wiki.opnfv.org/​_media/​requirements_projects/​timeline_doctor_r1.png +
-    * Milestone for First Spec ready might be put on OPNFV hackfest in Prague +
-    * Submit blueprints to Kilo has been Postponed +
-    * Action: Ryota to revise timeline table +
-  * Gap Analysis. +
-    * Third gap has been added to the etherpad (Fencing instances of an unreachable host in Nova) https://​etherpad.opnfv.org/​p/​doctor_gap_analysis +
-    * Please all review / add new gaps to the etherpad +
-  * Implementation Plan +
-    * Discussion last week on good candidate monitoring projects for Doctor project +
-    * Need also to work on implementation plan / architecture.  +
-    * Action: Tomi (Nokia) to come up with high level architecture proposal +
-  * List of tasks +
-    * Task 1 (Ryota) +
-      * Timeline milestone planning +
-    * Task 2 (Gerald) +
-      * Fault Table +
-    * Task 3 # punt +
-      * Gap Analysis +
-    * Task 4 (Tomi) +
-      * High level arch +
-      * Out-side of Nova arch first, Nova +
-      * One view for this here: http://​blog.russellbryant.net/​2014/​10/​15/​openstack-instance-ha-proposal/​ +
-      * Here is a picture for discussion to ipmlement outside of Nova: https://​wiki.opnfv.org/​_media/​doctor-opnfv-proposal.pptx +
-    * Task 5 (Ryota) +
-      * Wiki update (meeting minuts and so on) +
-    * Task 6 # TBD +
-      * NB I/Fs +
-      * Messaging +
-      * Information elements +
-      * Impl. plan(Gathering faults) +
- +
-==== Jan 12, 2015 ==== +
- +
-Agenda: +
- +
-Minutes: +
- +
-  * Fault table: https://​wiki.opnfv.org/​doctor/​faults  +
-    * Action: check and revise / update / extend +
-    * Some faults are specific to a certain HW other are more general +
-    * We should try to come up with a high level description of common faults +
-    * Proposal not to go to such level of detail.  +
-    * Keep one fault table and use the current fault table for study of the scope of Doctor +
-    * Are there other faults that cannot be detected by SNMP and Zabbix_agent?​ +
-    * We need a tool in Doctor that can retrieve such alarms. Should this tool be integrated with OpenStack or be independent?​ Should be kept open; +
-      * different tools may be used given clear interfaces are specified +
-      * Monasca: https://​wiki.openstack.org/​wiki/​Monasca OpenStack project for monitoring of faults; still in its early days +
-  * ETSI meeting in Prague: proposal to meet there +
-    * https://​etherpad.opnfv.org/​p/​HackfestFeb23 +
-    * Action: update your participation on that EtherPad page +
-  * Doctor "​working page": https://​etherpad.opnfv.org/​p/​doctor_gap_analysis +
-    * Action: edit this page for ongoing work on the gap analysis +
-  * Doctor wiki page updated +
-    * Use cases moved to extra page: https://​wiki.opnfv.org/​doctor/​use_cases +
-  * Timeplan: +
-    * Action: Ryota to prepare a timeplan/​timeline +
-    * Timeplan can be checked in each week's meeting +
-      * seems we are behind initial time plan (see https://​wiki.opnfv.org/​_media/​doctor_141208.pdf slide 11) +
-    * Reminder: some documents should be available by March +
-  * Next meeting: Jan 19th +
- +
-==== Dec 22, 2014 ==== +
- +
-Agenda: +
- +
-  * work item updates +
-  * Fault table +
-  * GAP analysis template +
-  * Wiki pages +
- +
-Minutes: +
- +
-  * Work item updates +
-    * Fault table +
-      * Status: waiting Palani'​s initial commit +
-      * Tomi also made initial list of faults. +
-      * TODO(Tomi): Open new wiki page to share the fault list +
-    * GAP analysis template +
-      * Ryota explained GAP analysis template drafted on https://​etherpad.opnfv.org/​p/​doctor_requirement +
-      * TODO(Ryota):​ Open new etherpad page for Gap Analysis with the template +
-    * Wiki pages +
-      * Our plan for wiki/doc structure seems to be OK, cause there was no question and objection in the past week. +
-      * TODO(Ryota):​ Update wiki pages +
-  * Fault notification at the Northbound I/F +
-    * Critical faults +
-      * It was agreed that we should characterize faults as critical ornon-critical when reporting to VNFs. +
-      * We must report all critical faults northbound. We may report some of the non-critical faults, need further study. +
-    * Fault aggregation +
-      * Discussed whether toaggregate different alarms and faults before notifying via northbound interfaceto VNFs. +
-      * General agreement that there should be some level of aggregation,​ butneed to figure out what events need to be aggregated. +
-      * Some suggested that VNFs should be notified only if the faults are urgent. +
-    * Notifying data center operations folks about hardware faults is something that seems to be out of scope for this project. Tomi: I think they need the information and there should not be a duplicate mechanism to detect faults to be able to make HW maintenance operations. Surely they will not need the notification that we would send to VNFM, but the actual alarm information we are gathering to make those notifications. Anyhow I agree that this is not in our scope and tools like Zabbix that we could use here can easily be configured then for this also in case HW owner is interested. +
-    * Why should warnings be sent to VNFs (such as cpu temp rising but notcritical yet)? VNFs might want to take action such as setup/sync hot standbyand this could take some time. +
-  * Are there open souce projects already to detect hypervisor or host OS faults? +
-    * OpenStackNova devs said it should be kept simple, providers need to monitor processes ontheir own. +
-    * But there appears to be some open source tools(SNMP polling or SNMP agents on host). Need to pull things together. +
-  * Next call will be on January 12th. +
- +
-==== Dec 15, 2014 ==== +
- +
-Agenda: +
- +
-Minutes: +
- +
-  * wiki/doc structure +
-    * Agreed to have three sections +
-      * UseCase (High-level description) +
-      * Requirement (Detail description,​ GAP Analysis) +
-      * Implementation(includes monitor tools and alternatives) +
-  * Faults table +
-    * will create table that explain stories for each fault +
-    * columns would be physical fault, how to detect, effected virtual resource and actions to recover +
-    * in three categories Compute, Network and Storage, will start on Compute first +
-    * also try to keep separate table/​categories for critical and warning +
-    * TODO(Palani):​ provide fault table example +
-    * TODO(Gerald):​ create first version of fault table after getting table example +
-  * framework +
-    * how we handle combination of faults and feature H/W faults that is still open question +
-    * suggestion to have fault management "​framework"​ that should be configurable to define faults by developers or operators +
-  * Gap analysis +
-    * We should have list of items so that we can avoid duplicated work +
-    * TODO(Ryota):​ Post first item to show example how we describe that could be template for GAP analysis +
-  * Monitoring +
-    * We should check monitoring tools as well: Nagios, Ganglia, Zabbix +
-  * Check TODOs from the last meeting +
-    * seems almost all items have done or started (but we could not check 'fault management scenario based on ETSI NFV Architecture'​ although there is silde on wiki) +
-  * Next meetings +
-    * Dec 22, 2014 +
-    * Jan 12, 2015  # skip Jan 5th +
- +
-==== Dec 8, 2014 ==== +
- +
-Agenda: +
- +
-  * How we shape requirements +
-  * Day of the week and time of weekly meeting +
-  * Tools: etherpad, ML, IRC? +
-  * Project schedule, visualiztion of deliverables +
- +
-Minutes: +
- +
-  * How we shape requirements +
-    * Use case study first +
-    * Gap Analysis should be included existing monitoring tools like Nagios etc. +
-    * How we format fault message and VNFD elements for alarms? +
-    * Fault detection should be designed within a common/​standard manner +
-    * Those could be implement in existing monitoring tools separated from OpenStack +
-    * What is "​common"​ monitoring tools, there are different tools and configurations +
-    * Focus on H/W faults +
-    * Do we really need that kind of notification mechanism? Can we use error from API polling, just get error detected by application or auto-healing by VIM? +
-      * Real vEPC needs to know fault that cannot be found by application like abnormal temperature. +
-      * VIM should not run auto-healing for some VNF. +
-      * There are two cases/​sequences defined in ESTI NFV MANO that fault notification are send from VIM to VNFM and to Orchestrator. +
-      * Alarming mechanism is good to reduce the number of request from user who pooling virtual resource status. +
-    * We shall categorize requirements and create new table on wiki page. (layer?) +
-    * -> A general view of the participants is to have the 'HW monitoring module'​ outside of OpenStack +
-    * TODOs +
-      * Open etherpad page for collaborative working (Ryota) +
-      * Collect use cases for different fault management scenarios (Ryota) +
-      * Set IRC (Carlos) +
-      * Provide Gap Analysis (Dinesh, Everyone) +
-      * Provide fault management scenario based on ETSI NFV Architecture (Ashiq) +
-      * List fault items to be detected (Ashiq, Everyone) +
-  * Day of the week and time of weekly meeting +
-    * Monday, 6:00-7:00 PT (14:​00-15:​00 UTC) +
-    * TODO(Ryota):​ create weekly meeting entry in GoToMeeting +
-  * Tools: etherpad, ML, IRC? +
-    * We will use opnfv-tech-discuss ML with "[doctor]" tag in a subject. +
-    * We will use "​opnfv-doctor"​ IRC channel on chat.freenode.net . +
-    * TODO(Carlos):​ update wiki +
-  * Project schedule, visualiztion of deliverables +
-    * All team members are asked to check project proposal page and slides that are approved by TSC and show our schedule and deliverables. +
-    * Northbound I/F first specification by Dec 2014. +
- +
-==== Dec 1, 2014 ==== +
- +
-Agenda: +
- +
-  * Project Proposal Refinement +
-    * https://​wiki.opnfv.org/doctor/​project_proposal +
-    * Project Categories +
-    * Deliverables and Schedule - SR +
- +
-Minutes: +
- +
-  * Project proposal +
-    * There were two comments at project review in TSC meeting (Nov 26) +
-      * Large scope: TSC asked to narrow project scope, creating as requirement projects seems reasonable +
-      * Overlap with HA project, so collaborate in project activity +
-      * https://​wiki.opnfv.org/​requirements_projects/​high_availability_for_opnfv +
-    * Ashiq and Qiao had talked before this meeting, and agreed that we would not eliminate duplication at proposal phase +
-    * Project proposal was fixed by some members +
-      * https://​wiki.opnfv.org/​doctor/​project_proposal +
-      * The project categories was changed to requirement only +
-      * In new revision of project proposal, we removed detailed descriptions which don't suit requirement project +
-      * Links to original project proposal are replaced to point the new page, and the link to the old page that described further details can be found at the bottom of the new proposal page +
-      * We should not edit the proposal page after TSC approval to keep evidence what we planed at the beginning of the project +
-      * "Auto recovery"​ is missing, will continue discussion in mail with clarification by Tomi +
- +
-==== Nov 17, 2014 ==== +
- +
-Agenda: +
- +
-  * Scoping and Scheduling (what feature to be realized in what time frame) +
-  * Resources available and necessary for this project +
-  * Technical aspects and relevance to upstream projects +
-  * How to socialize with upstream projects +
- +
-[[doctor_minutes_20141117|Minutes]] +
doctor/meetings.txt · Last modified: 2015/09/19 13:36 by Ryota Mibu

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki