You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

 

Attendees: Heather Kirksey Jim Baker Lincoln Lavoie Brandon Wick Georg Kunz

Problem statement:

  • Open source development (Dovetail) community dissolved 
  • Lacking skill set in UI development - Intracomm was contracted
    • Original portal leveraged from OpenStack


https://unh.zoom.us/my/lylavoie ←  Brandon join here!!!



Requirements

This list of requirements should be expanded in level of detail to support an RFP:

  • General requirements
    • the portal must at least provide the same functionality as today's portals (see https://nfvi-verified.lfnetworking.org/#/ AND https://vnf-verified.lfnetworking.org/#/)
    • the 2 portals will be combined into 1 with menus, toggles, and a search function to find the different badge types, companies, and products. 
    • high-level use cases 
      1. Support upload, validation, display, sharing, and manage test results and application by "user"
      2. Support a review workflow of test results by "reviewers"
      3. Publicly list companies and products which have obtained a badge in a "marketplace", as marked by "admin"
  • Integration of different OVP programs
    • the web portal must integrate different types of OVP programs (e.g. NVFI, VNF, ...)
    • today, the VNF and NFVI program use separate web portals basically providing the same functionality, only differing in the validation of test results.
  • user roles
    • "user"
      • can upload and manage test results
      • can only see own test results
    • "reviewer"
      • can see all test results marked as "for review" by its "user" (the user is the owner of the results / application)
    • "admin"
      • can manage user roles
      • can manage (create, update, delete) entries to the marketplace
  • test result management
    • authenticated users (role "uploader") must be able to
      • upload test results
      • edit meta data of a test result set (product name, etc.)
      • view and edit only their own test results
      • change status of a test result between "private" and "for review"
  • review management
    • authenticated reviewers (user role) must be able to
      • access all test results set to state "for review"
      • cast a vote (-1, 0, 1) on every instance of test results


  • OVP release management
    • management of releases of OVP (create new, edit, delete) must be runtime operations, i.e., not requiring new versions of the portal
    • a OVP release comprises
      • documentation
      • a unique test result schema for test result validation and display


  • validation and display of test results (see also terminology below)
    • the web portal must validate uploaded test results by comparing the "test result summary" to a "test result guideline"
      • "test result guideline": source of truth
        • list of all test cases which are part of a given OVP release
          • use case: detect if test cases are missing from uploaded test results
        • the expected result for passing each test case (functional tests: "pass", non-functional: "value")
        • stored in web portal only
      • "test result summary"
        • part of the "test result package" generated by test tool
        • json formatted
        • should include in addition to today (AP on test tooling team)
          • OVP release ID (e.g. 2020.10)
          • OVP program type (e.g. NVFI, VNF, ...)
        • example of a "test result package" currently generated by test tooling:
    • optional requirements, requires close collaboration with and input from test tooling team
      • define a schema for formal validation of test result summary
      • define a schema for formal validation of test result guide



  • portal lifecycle management
    • all management operations on test results, market place entries, users, and new releases of OVP must be runtime operations not requiring new builds of the web portal
    • separation of LCM of the portal instance (responsibility of LF IT) and content (responsibility of OVP admins)


  • Marketplace management
    • "marketplace admins" (user role) must be able to manage entries of the marketplace (create, edit, delete)
    • all entries of the marketplace must be stored in persistent storage
    • market place data items per entry: see current fields + <add more if needed, Brandon?>


  • user management
    • allow for managing users and roles based on LF IDs
    • roles: reviewer, uploader, admin


  • Terminology
    • "test result package": archive containing "test result summary" file and individual logs
    • "test result summary": json formatted file containing a summary of all test cases / one run of the compliance test tool
    • "test result guideline": json formatted file containing all tests which are part of an OVP release + expected result for passing a test



Requirements (as noted during the call on :

  • Development
    • Represent the workflow of the respective participants
      • xtesting results uploaded - schema for uploads
      • portal to validate/accept inputs - version checking
      • Allow authorized set of people to manage the badging administration
    • No regression of functionality from Dovetail implementation
    • Alignment of results formats from ONAP/OPNFV
      • ?Allow all versions to be uploaded - deprecate older versions?
        • Bring forward existing badging - unlikely to support old schema/results 
        • Minimum: current xtesting and ONAP results - schemas
    • Converged portal (VNF/NFVIs/CNF) 
    • Built on LF infra (shared vs. dedicated)
    • Desire portal to be managed without LF IT interactions 
    • Naming changes?
      • Define that early
    • User management
      • integrated with LF SSO 
      • Privileged users for management
    • 3rd party OVP lab integration 
    • Use existing portal as a basis for MVP definition
    • Timeline?
      • Objective: full MVP implementation - Oct 2020 (ONES Sept 28)
        • Public availability
        • Migrate existing data
        • Internal Go-Live –  
        • Development time – start  
        • Review submissions to RFP
        • RFP open time –  
        • RFP definition complete –  
        • Budget setting/approval – LF GB  
        • Vendor qualification - at least 3 vendors
      • Support for incoming data sets and badging processes
  • Hosting
  • Maintenance
  • Georg Kunzto expound on requirements by  




  • No labels