| Table of Contents |
|---|
Requesting QA Testbed Resources
The process of requesting resources within the QA testbed infrastructure is managed via the Help Desk and maintained by WP9 Task 2. The Help Desk service, based on JIRA, allows the GÉANT QA testbed request system to request Virtual Machines that have a specified capacity. In particular, the Help Desk service enables the following actions:
- Creating a Virtual Machine with well-defined capacity and features.
- Running the VM in the requested time frame.
- Suspending the VM outside a requested time frame.
- Closing or deleting a VM.
- Creating a snapshot of a VM in a specific state.
- Loading/reloading a VM with a new instance of an operating system (Ubuntu or CentOS).
- Loading/reloading a VM from a specific snapshot.
- Re-assigning resources to a VM, if such resources are available.
| Info | ||
|---|---|---|
| ||
The Help Desk provides facilities for managing the VM environment at the level of virtual machines. All the aspects related to the maintenance of the particular operating system running on the assigned Virtual Machine are handled by an appointed member of a specific development team, who is given operating system root level privileges. |
QA Testbed Request Description
To request a Virtual Machine or actions to be carried out on a VM, the GÉANT QA testbed uses JIRA issues. This means that if you want to request a new VM you need to create an issue in JIRA's GÉANT QA testbed project. You can requests the following VM types:
...
It is recommended that you provide the description of the requested action (i.e. the text of one of the bullets listed above) as sub-task summary.
When a VM is closed, its corresponding issue is closed in JIRA.
Accessing QA Testbed virtual machine
Once a VM is created and assigned to the requestor, the VM is available via SSH. Developers are required to login by using SSH keys. In fact, login with passwords for SSH is disabled by default.
Virtual machines have ports 80 and 443 open.
As far as operating systems are concerned, currently Ubuntu server and CentOS are available.
Developers assigned to the requested machines have full root access to the machine, however, once the machine is broken, it will be simply rebuild from scratch and handed over again.
In case of problems with accessing the services on other ports (e.g. tomcat 8080) you can change service default port (see service administration guide). If you do not want to change service configuration, you can configure http proxy with e.g. nginx http and reverse proxy server (http://nginx.org/en, License BSD-like). If other port need to be open please request new sub-task issue with the request (with information port number and tcp/udp/both).
QA Testbed Resources and Limitations
The QA Testbed delivers virtual machines hosting Linux operating systems (Ubuntu, CentOS), dedicated to GN development teams as demo or testing instances. The QA Testbed hosts VMs assigned permanently to development teams as well as up to 50 Virtual Machines running in parallel and assigned to development teams on a resource-booking basis. Such limitations are due to hardware constraints and a number of assigned public IP addresses.
QA Testbed Procedures
The procedure for requesting virtual machine resources (with CentOS or Ubuntu OS) in the QA testbed is managed through Help Desk. The GÉANT QA testbed JIRA allows you to request the actions described below. The resource can be requested as a fixed VM (assigned permanently to a development team) or as a temporary VM (assigned for a particular time window). As far as the number of fixed VMs is concerned, initially development teams are assigned to the VMs according to the figures given at the time the requirements were specified. The QA testbed calendar shows the confirmed bookings of VMs that are already running, and can be used to check if resources might be available (approximate number of available resources = overall capacity of the QA testbed - resources assigned to already running VMs at a given date). However, the calendar does not guarantee that there are free resources, as there might be requests that are already being processed. The issue creation timestamp determines the order in which tickets are dealt with and resources assigned to VMs.
...