This page describes the requirements for a lab to participate in Lab as a Service. The reference implementation can be found at: https://git.opnfv.org/laas-reflab/tree/
The API
The dashboard is the single source of truth, and communicates tasks to the lab through the api. You can read the api spec on this page: Developer Documentation
The API is how the dashboard tells the lab about a booking from a user, and how the lab communicates information back to the user. To participate in LaaS as a lab, you need to implement your end of the API. The rest of the document describes the pre-built backend system that the LaaS project has built, but you are free to implement your own system if the pre-built one does not fit your needs.
Reference Architecture
Networking Requirements
- Stackstorm must be able to reach everything:
- The LaaS dashboard on the internet
- The IPMI interfaces on the LaaS servers
- The mangement IP of the LaaS switches
- The management and public IPs of the LaaS servers
- FOG
- The VPN server
- FOG must be able to PXE boot the LaaS servers
- The gateway / vpn server must:
- Route vpn traffic to / from the LaaS machines
- Allow the LaaS servers to reach the internet
- Serve DHCP and DNS such that:
- A server is always reachable by its hostname, regardless of what network it is on
- Servers will always PXE boot through FOG
Description
The reference implementation relies heavily on Stackstorm, a nice automation server: https://stackstorm.com/. This is what does all the communication with the dashboard API and configures the switches + servers as required. This is where all the code and logic of the reference implementation lives.
FOG (Free Opensource Ghost) is used as a way to quickly backup and restore disk images: https://fogproject.org/. This is how we reinstall the servers on a new booking: FOG will PXE boot the servers and write a clean disk image.
A more detailed description of how deployments work can be found in the reflab repo: https://git.opnfv.org/laas-reflab/tree/README