====== Gap Analysis on OpenStack for DPACC ======
Attendants: Lingli, Keith, Bob, Paul, Howard, Mario, Ola, Micheal, Rajesh

  * [[https://docs.google.com/document/d/1_fOinIQNcPwNODZPzGK5vRMPJQLwL7iLds4NFnjXSms/edit?usp=sharing|gap analysis on openstack]]
  * Lingli goes through the latest update on the doc summarized in {{:dpacc:gap_analysis_on_openstack_for_dpacc-update_discussion_20160204.pptx|update discussion}}
  * Update Summary
    * Minor editing on Section 1-3
    * Merge Section 4 "Requirements" with Section 5 "Gap Analysis". Requirements are grouped with the specific lifecycle management. And gaps are intended to be added accordingly
      * Add EPA introduction to the new Section 4 "Gap Analysis"
      * The Current layout of the Section for "Gap Analysis" 
        * 4.1 Openstack Background: Basic Functions, EPA Introduction, Proposal: Dedicated Acc Management
        * 4.2 Accelerator Life Management: Resource Discovery, Resource Selection, Resource Allocation, Resource Update, Release
        * 4.3 Summary: Requirements, Gaps
  * Comments & Feedback{{:dpacc:gap_analysis_on_openstack_for_dpacc-update_discussion_20160205.pptx|slides(with comments)}}
    * On Page 7 for "Nova Extension vs NOMAD"
      * The current table groups CPU instruction set extensions into the category that should be exposed the NOVA way.
        * Some of them, for instance Intel AES-NI and AVX2, can also be exposed as software implementation for abstract accelerator and be managed by NOMAD. (Keith)
        * Need another review and grouping accordingly. (Lingli)
        * Add a column for abastracted accelerator types to be supported by NOMAD. (Micheal)
      * In the table, "VMs direct access to accelerators" is stated as one of the pros for NOMAD way
        * Need clarification on this “VM direct access to accelerator. Does it not supporting Virtio interface access of accelerator from VM? (Bob)
        * Virtio is meant for data path access. (Howard)
      * For the Cons of NOMAD way, there is potential scalability issues for NOMAD, as the number of compute nodes under its management increases. (Paul)
        * Agreed. (Howard)
        * Will bring workflow design to discussion later which needs to take this into consideration. (Lingli)
    * On Page 8 for "Requirements for Resource Discovery"
      * A new requirement is proposed
        * Requirement VIM (or AC?) SHOULD maintain the mapping (change to mapping dependency?) between abstract acceleration resource to physical acceleration resource.
        * Remaining issues to be addressed/confirmed
          * Who should maintain the mapping, VIM or AC? Howard prefers VIM.
          * Should we change "mapping" into "mapping dependency"? Micheal suggests the latter.
          * Lingli suggests to post these questions to the online doc for feedback.
      * Keith feels the need to include also notification scheme when an accelerator break down. Lingli explains that there are corresponding requirements on "fault management" for "resource release" in following sections.
    * On Page 9 for "Acceleration resources features", which is aligned with ETSI NFV IFA004
      * Bob will bring more feedback after team review later.
      * Micheal is confused about the relationship between IFA004 and this document. Howard clarifies that IFA004 is high level considerations, while this doc is more focused on implementation gaps.
    * On Page 10 for "Gaps for Resource Discovery"
      * For the current example for Metadata definition, Keith feels it is too low level detail to be included in the current doc. Lingli agrees.
      * For the current API definition example, Bob will bring more feedback after team review later.
    * Page 10-15 are left for further discussion due to time limit


===== Follow-up Actions =====
  - Update the doc according to the comments during the call (Lingli)
  - Refine the table for "EPA v.s NOMAD" and post it to the online doc, for further feedback (Michele)
  - Refine work plans in Section 5, and bring Nomad Architecture and workflows to the next discussion (Lingli&Howard)

====== DPACC Use-cases ======

  * [[https://docs.google.com/document/d/1eu2489SYeVL180ZzjnagrXTUM1Qh37GKs6N6rRYDVNM/edit?usp=sharing|DPACC Usecases]]
  * Lingli goes through the table of contents and calls for further review and feedback online
  * Rajesh adds a subsection for "DPDP offload acceleration usecase"
  * Lingli adds a subsection for "vRAN" as another "targeting applications"

===== Follow-up Actions ====

  - Summarize the current documents and call for review in the list (Lingli)

====== About Next Discussion ======
  * DPACC calls are canceled for next week, for the approaching Chinese New Year.
  * Lingli will continue work on Requirements and Gaps for the other four management phases (Resource Selection, Allocation, Update and Release) bring them to our further discussion.
  * Rajesh will continue work on common g-API for virtio-XXX acceleration usecases and bring it to our next discussion.