Skip to end of banner
Go to start of banner

OVP Portal Requirements

Skip to end of metadata
Go to start of metadata

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