User Tools

Site Tools


doctor:meetings

This is an old revision of the document!


Doctor Team Meetings

Info

  • Call Logistics: GoToMeeting
    • Web Access
    • Phone
      • Meeting ID / Access Code: 409-154-429
      • Audio PIN: (Shown after joining the meeting)
      • Dial in number:
        • Canada: +1 (647) 497-9351
        • France: +33 (0) 182 880 459
        • United Kingdom: +44 (0) 330 221 0086
        • Australia: +61 2 8355 1024
        • Netherlands: +31 (0) 208 080 381
        • New Zealand: +64 (0) 4 974 7214
        • Denmark: +45 (0) 69 91 88 64
        • Italy: +39 0 553 98 95 67
        • United States: +1 (215) 383-1010
        • Austria: +43 (0) 7 2088 1403
        • Belgium: +32 (0) 38 08 1856
        • Sweden: +46 (0) 852 503 499
        • Germany: +49 (0) 692 5736 7210
        • Switzerland: +41 (0) 435 0167 09
        • Finland: +358 (0) 942 41 5780
        • Spain: +34 955 32 0845
        • Ireland: +353 (0) 14 845 978
        • Norway: +47 21 03 58 98

Past meetings

  • 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 virtualresource and actions to recover
        • in three categories Compute, Network and Storage, will start onCompute 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 tableexample
      • framework
        • how we handle combination of faults and feature H/W faults that isstill open question
        • suggestion to have fault management "framework" that shouldbe 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 thatcould 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
    • Logistics
    • Agenda
    • Minutes
      • Project proposal
        • There were two comments at project review in TSC meeting (Nov 26)
        • 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
          • 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
      1. Scoping and Scheduling (what feature to be realized in what time frame)
      2. Resources available and necessary for this project
      3. Technical aspects and relevance to upstream projects
      4. How to socialize with upstream projects
    • Logistics
doctor/meetings.1422865367.txt.gz · Last modified: 2015/02/02 08:22 by Ryota Mibu