LaaS Community and Governance
- LaaS is governed by the OPNFV TSC. Day-2-day business for LaaS is handled by the OPNFV Infra Working Group.
- LaaS is available to all LFN communities, i.e. OPNFV, ONAP, OpenDaylight, FD.io, PNDA, Tungsten Fabric.
- LaaS access policy evolves with the overall evolution of the LaaS program (see details below)
LaaS Evolution: Development Timeline
Laas 1.0 (MVP - launched February 2018):
Product Description:
- Book a single server using the dashboard
- Selected OS installed (Ubuntu, CentOs, Suse)
- Generate and send out access information automatically
Usage / Uptake:
- Typically 50%-80% utilization of servers, with peaks associated to plugfests or other industry events pointing towards the LaaS resources.
Usage Policy
- Eligible users: Anyone with an LF account
- Number of servers per booking: 1
- Maximum number of concurrent bookings per user: no limit
- Maximum length of a booking: 3 weeks
- Booking extensions: Yes. Maximum of 2 extensions, 1 week each
LaaS 2.0 (ETA Fall 2018)
Product Description:
- Evolution from MVP (LaaS 1.0): Allow to book multiple bare metal servers, rather than a single one.
- Dynamic POD Allocation
- Allow user to design and book a set of servers with networks between them
- Dashboard will generate PDF for user defined POD
- Smaller features and improvements
- Multi-user bookings (i.e .adding cohorts to your booked resources, so separate VPN access doesn't have to be requested out of band)
- Allow users to save a "snapshot" or their system(s), and re-deploy that image at a later date
- Support for additional labs in the dashboard.
Usage Policy:
LaaS 2.0 introduces the ability to book a cluster of bare-metal servers. Usage policy differs for single and multi-server bookings.
- Single server bookings (same as LaaS 1.0):
- Eligible users: Anyone with an LF account
- Number of servers per booking: 1
- Maximum number of concurrent bookings per user: no limit
- Maximum length of a booking: 3 weeks
- Booking extensions: Yes. Maximum of 2 extensions, 1 week each
- Multiple server bookings:
- Eligible users: Project Technical Leaders (PTL) only. During the booking process, the PTL will need to authorize by providing a pointer to an INFO file in git repo of a LFN project that shows her/him as PTL of that project.
- Maximum number of servers per booking: 8
- Maximum number of concurrent bookings per user: no limit
Note: We expect that PTLs communicate among each other to ensure that resources are shared fairly. In case this does not work out, a more constrained policy will be put in place. - Maximum length of a booking: 3 weeks
- Booking extensions: Yes. Maximum of 2 extensions, 1 week each
LaaS 3.0 (Official LaaS offering - ETA: "Laas 2.0 + 4-6 weeks"):
Product Description:
- Automatic deployments (virtual or bare-metal) of OPNFV on top of user defined POD;
See also Lab as a Service#LaaSFlowProposal- Only supported for installers supporting PDF (pod descriptor files)
- Available 4-6 weeks after LaaS 2.0
Usage Policy:
Same as LaaS 2.0.
LaaS 4.0 (Extended LaaS offering):
Product Description:
- Automate installation of other LFN projects
- Available TBD (details are to be defined)
Usage Policy:
Same as LaaS 2.0.
Background: Evolving Objectives for LaaS
- LaaS original objectives - as approved by the former OPNFV board:
- LaaS definition: Lab as a Service#WhatisOPNFVLaaS
- LaaS initial set of use cases: Lab as a Service#OPNFVLaaSinitialuse-cases
- LaaS deployment approach: Lab as a Service#LaaSFlowProposal
- Evolution Objective #1: Now that OPNFV is part of LFN, start to make LaaS available to the entire LFN
- Offer LaaS to other communities within the LFN and make it applicable to the other communities in the LFN: ONAP, OpenDaylight, FD.io, PNDA, SNAS, Tungsten Fabric.
- Several LFN projects (e.g. ONAP, PNDA) are quite resource intense.
- Example ONAP: OOM install would fit a single server (https://onap.readthedocs.io/en/beijing/guides/onap-developer/settingup/onap_oom.html#installing-onap-k8s) whereas the Heat-based install requires more resources than a single LaaS server can offer (https://onap.readthedocs.io/en/beijing/guides/onap-developer/settingup/onap_heat.html#installing-onap-heat).
- Example PNDA: http://pnda.io/pnda-guide/provisioning/platform_requirements.html
- Evolution Objective #2: Leverage learnings from initial phase of LaaS ("MVP - see below")
- Enable additional use cases (example: LaaS use case: Project Auto), which require a "bare metal" environment of multiple servers.
- Define and manage usage-policies of LaaS:
- The simple MVP (single server with operating system) is already utilized at 50%. Access restrictions are minimal (LF account is sufficient for LaaS access)
- Larger community (all LFN) combined with more flexible deployments (one or multiple servers) requires closer and tighter control to ensure that resources are shared fairly.
References, Previous Discussions & Presentations
- Lab as a Service - main LaaS wiki page
- OPNFV LaaS Update to the TSC
- LaaS Update during the Plugfest
- LaaS Presentation at ONS