Page tree
Skip to end of metadata
Go to start of metadata
Use Case NameDescriptionExpected User TypesHardware requirements
(Hardware examples)
Provided byNotes / Discussion

developer (software)

Access to a vPOD for the purpose of working on various OPNFV projects.

This specific use case would support development of projects that don't require higher performance or specific hardware requirements.

The provisioned environment can vary from just having base OS to all in one OpenStack to HA OPNFV Scenario.

  • developers from different type of projects (installer, feature, test, etc.) implementing new features, integrating components, writing test cases.
  • students/interns.

single server with virtual pods

Hardware example:

community 
developer (hardware)

Access to a baremetal POD for the purpose of working on various OPNFV projects. This specific use case would support development of projects that require higher performance or specific hardware requirements.

The provisioned environment can vary from just having jumphost provisioned and the rest of the nodes with no OS at all to full blown HA OPNFV Scenario.

  • developers from different type of projects (installer, feature, test, etc.) implementing new features, integrating components, writing test cases.

Pharos pod hardware:

Hardware example:

community or LF 
demoAccess to a pre-deployed pod, for the purpose of trying or demonstration a working deployment of OPNFV / OpenStack.end user(maybe not member of OPNFV)

single server with virtual pods

Hardware example:

community or LF 
xci 

upstream community:

  • openstack
  • opendaylight
  • FD.io
  • ovs

 

virtual pods or physical pods 

I'm not sure we can support this in the LaaS, as the pods are not expected to be controlled by Jenkins, or to be "long lived", etc.

XCI has no dependency to Jenkins, etc and the lifetime of the deployment is not relevant. The point with XCI is to have ability to deploy latest verified versions of different components or even patches.

ONAP developer

OPNFV scenarios are deployed on-demand for ONAP developers to test against their ONAP deployments (in another lab, connected to OPNFV LaaS over VPN), as needed for specific NFVI features or to work with specific OPNFV distros (the rest of ONAP devs are fine with generic/public clouds for testing VNFs).

ONAP developer

10 virtual servers (5-10 physical servers) on avg consumed for ONAP devs, per the assumptions:

  • A partially or fully allocated Pharos compliant POD server, to run a virtual OPNFV scenario deploy and deploy VNFs for testing
    • typical small/medium VNF (e.g. vRouter, vFW, vLB, vDNS, vPE, vCE): 50% of a server
    • typical large VNF (e.g. vEPC, vIMS): 1 full server  
  • 25% of ONAP developers spending avg 4 hours per day testing with the OPNFV LaaS resources
    • 5% of ONAP developers active on OPNFV LaaS resources at any one time (assuming even timezone-distribution)
    • thus for ~150 ONAP devs, <10 active devs at any one time

See also: https://wiki.onap.org/display/DW/ONAP+Lab+Specification

  
ONAP X-CIA new or existing OPNFV deployment is used for X-CI runs to verify tests against ONAP code changes. An existing OPNFV deployment (refreshed as needed) can be used to test against multiple ONAP X-CI jobs to reduce X-CI overhead (resources, test duration). A new deploy can be used if the type of X-CI job requires it (why is TBD).OPNFV X-CI team

At least one LaaS virtual server (existing deployment), or multiple (TBD) per X-CI job forecast

 

  
OPNFV+ONAP developerNew or existing OPNFV deployments are used for OPNFV devs to test OPNFV+ONAP integration. Several OPNFV scenarios can be used in parallel to verify multi-VIM or scenario-focused tests (e.g. NetReady).OPNFV developerProbably up to 5 physical servers (5-10 virtual servers for distinct scenarios) for ongoing ONAP integration testing.  
  • No labels

1 Comment

  1. some feedbacks:

    1. "512 GB of DDR4 ECC RAM" for singer server, is this requirement a bit higher? 128GB or 256GB OK for this(16GB*5 + 8GB*1)?
    2. XCI belongs to CI, and I think this will be resolved in CI resources. If we consider XCI supported in LaaS, shall we support all current installers in LaaS?