You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »


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.


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:

  • fixed resource (fixed VM type) assigned to a development team permanently
  • temporary resource (testing VM type) assigned to a development team for a requested time frame

When you create an issue to request a VM, you specify the requested OS type, capacity, usage time frame and other important features. In particular:  

  • GN3 development team (e.g. perfSONAR|AutoBAHN|cNIS|I-SHARe)
  • Processor assignment (2GHz, 2x2GHz)
  • RAM memory assignment (2GB RAM, 4GB RAM)
  • HDD space (up to 50GB)
  • OS type (Ubuntu  | CentOS)
  • Time frame  to be booked (from-to or unlimited in case of fixed VMs dedicated to a development team)
  • domain name (e.g. autobahn-1)
  • User to be assigned OS root privileges

To request an action to be carried out on an existing VM (e.g. a maintenance action), you need to modify this VM's issue by creating sub-tasks for it. The sub-tasks cover the following actions:

  • Requesting a VM snapshot.
  • Requesting loading/reloading of a VM with a snapshot or fresh image.
  • Changing resource assignment for a particular VM (GHz, RAM, HDD).
  • Requesting a VM to be suspended/closed.


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.
 

Requesting a VM to be created  (permanent or temporary VMs)


 To request a virtual machine in a QA testbed environment:

1.   Create a new issue in the GEANT QA testbed requesting system,
2.   Provide the required information:

  • GN development team, responsible for the VM ( e.g. perfSONAR | GTS | NMaaS )
  • VM type (fixed VM | testing VM). Fixed VM is assigned permanently to a team, whereas Testing VM is assigned within set timeframe.
  • Processor clock assignment (2GHz, 2x2GHz)
  • RAM memory assignment (2GB RAM, 4GB RAM)
  • HDD space (up to 50GB)
  • OS type (Ubuntu | CentOS)
  • Time frame to be booked (start date - end date or unlimited in case of a VM dedicated to a development team)
  • Domain name (e.g. autobahn-1)
  • User responsible for OS-level administration, who is assigned OS root privileges. A member of GN3 development team, responsible for the VM.
  • Summary of activities to be carried out on this machine (integration/system testing, performance testing etc.)

 

Note that:

  • Once the VM is created, the issue status changes to “CREATED”.
  • Once the time window begins, the issue status changes to “RUNNING”.
  • When the time window comes to an end, the issue status changes to “SUSPENDED” and the VM is stopped. If the VM is no longer needed, it is turned off and its status changed accordingly.

 
Requesting a VM snapshot


 You can request a snapshot of a particular VM via the GÉANT QA testbed Help Desk by creating a sub-task for an issue that is related to the VM you want the snapshot of. The limitation is two snapshot per virtual machine. The procedure is as follows: 

 

  1. Browse the issues submitted to the GÉANT QA testbed project until you find an issue that corresponds to the VM you want a snapshot of.
  2. Create a sub-task for the issue (e.g. from the More Actions menu). 
  3. Set the Issue Type to “Help Desk” and enter “Create snapshot of the VM” in the Summary field.
  4. In the Description field, specify the date you want the snapshot to be created.  
  5. Click Create to submit your request.

 

Once the snapshot is created you will receive confirmation.
 
 

Requesting the loading/reloading of the VM with a particular snapshot or new OS instance


 You can request a VM to be loaded from a particular snapshot via the GÉANT QA testbed Help Desk by creating a sub-task for an issue that is related to the VM you want the snapshot of. The procedure is as follows: 

 

  1. Browse the issues submitted to the GÉANT QA testbed project until you find an issue that corresponds to the VM you want to load from a snapshot.
  2. Create a sub-task for the issue (e.g. from the More Actions menu).
  3. Set the Issue Type to “Help Desk” and enter “Load a snapshot” in the Summary field.
  4. In the Description field, provide the name of the snapshot you want to be loaded.
  5. Click Create to submit your request.
     


Please bear in mind that the operating system with all applications and other dependencies will be replaced with the snapshot you requested.

 
Changing the resource assignment for a particular VM


 Once the resources are available, it is possible to increase the capacity of a virtual machine in terms of processor (GHz) and assigned RAM memory. This can be done where justified, i.e. when the history of VM utilization/load clearly shows that the VM resources are extensively used. 

To request resources to be extended:

  1. Browse the issues submitted to the GÉANT QA testbed project until you find an issue that corresponds to the VM whose resources you want to extend.
  2. Create a sub-task for the issue (e.g. from the More Actions menu).
  3. Set the Issue Type to “Help Desk” and enter “Extension of resources” in the Summary field.
  4. In the Description field, specify to what capacity you would like to extend and provide a reason for the extension.
  5. Click Create to submit your request.

 
The request will be analysed along with the load history of a particular VM, and confirmation will be sent whether the extension is reasonable and possible. 

 
Requesting VM to be suspended/closed


 If a permanently assigned VM is no longer going to be used, you should request the VM to be suspended to free up its resource for other requests. To do this:

  1. Browse the issues submitted to the GÉANT QA testbed project until you find an issue that corresponds to the VM whose resources you want to extend.
  2. Create a sub-task for the issue (e.g. from the More Actions menu).
  3.  Set the Issue Type to “Help Desk” and enter “Suspend the VM” in the Summary field.
  4. Click Create to submit your request.

 

As far as the temporary VMs are concerned, when the time window dedicated for a particular virtual machine is finished, the VM will be suspended and resources (GHz, RAM) reassigned to a common pool for new requests. The VM can be up and running in the next time window according to the reservation.

  • No labels