LaaS scenarios

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:

• Intel XEON E5-2699 v4 2.20 GHz, 145W, 22C, 55MB  (high number of cores (22), well suited to run VMs) - https://ark.intel.com/products/91317/Intel-Xeon-Processor-E5-2699-v4-55M-Cache-2_20-GHz

• 512 GB of DDR4 ECC RAM

• 2 x 10 Gbps NICs

• 0.9 TB of SSD (2 x 480G SSD)

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:

• 6 Servers Intel
  • Intel XEON E5-2667 v4 3.20 GHz, 135W, 8C, 25MB https://ark.intel.com/products/92979/Intel-Xeon-Processor-E5-2667-v4-25M-Cache-3_20-GHz)

  • 128 GB of DDR4 ECC RAM

  • 2 x 10 Gbps NICs or 100 Gbps NICs

  • .9 TB of SSD (2 x 480G SSD)
• 6 Servers ARM
  • (details to be added)
• Switch with > 12 x 10Gbps ports

single server with virtual pods

Hardware example:

• Intel XEON E5-2699 v4 2.20 GHz, 145W, 22C, 55MB  (high number of cores (22), well suited to run VMs) - https://ark.intel.com/products/91317/Intel-Xeon-Processor-E5-2699-v4-55M-Cache-2_20-GHz

• 512 GB of DDR4 ECC RAM

• 2 x 10 Gbps NICs

• 0.9 TB of SSD (2 x 480G SSD)

upstream community:

• openstack
• opendaylight
• FD.io
• ovs

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.

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).

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

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