Fedcloud-tf:WorkGroups:Scenario1

Main

Roadmap and Innovation

Technology

For Users

For Resource Providers

Media

Workbenches:

Open issues

Scenario 1 VM Management

Scenario 2 Data Management

Scenario 3 Information Systems

Scenario 4 Accounting

Scenario 5 Monitoring

Scenario 6 Notification

Scenario 7 Federated AAI

Scenario 8 VM Image Management

Scenario 9 Brokering

Scenario 10 Contextualisation

Scenario 11 Security

Scenario 1: Running a pre-defined VM Image

Leader: Michel Drescher, EGI; Matteo Turilli, Oxford e-Research Centre

Issues to follow-up/resolve

Following need to be considered with this scenario

1. Trust level and Auditing of the VM (since it has to run as Root access)
2. Different VMs needed based on underlying Infrastructure such as 64 vs 32bits Or VT enabled plus Xen vs KVM
3. Contextualization i.e. how users should login to this vm , how his public key transfer and active to login as root to this vm
4. Which libraries/versions/compilers will be installed by default?

From a user perspective (WeNMR contribution) we would like to:

1. Be able to install software on the pre-defined VM images (under the user account)
2. Be able to save those images (at least for a pre-defined time) (i.e. no new installation each time we wish to use the image)

Note:This section is heavily in-flux so the information given above might be slightly outdated. The minutes of the conference calls contain more information.

OCCI interface testing

The Task Force decided to use the OCCI interface as the canonical, task force-wide uniform interface for API-based VM Management. To ensure this uniformity (and applicability of the OCCI interface) a series of test cases are published and maintained that aim to cover all necessary funtionality to manage Virtual Machines.

Starting with two initial volunteer sites, the matrix testing effort explicitly aims at expanding out to Resource Providers that run other Cloud Management solutions such as:

• OpenStack (FZJ, OerC, etc),
• JClouds based providers (e.g. CloudSigma),
• proprietary solutions (GRNET)

once OCCI implementations become available for the respective solution in use.

Execution plan

The following is a list of actions that need to be accomplished in common

1. Use a reference VM that
   

• Allows a user to ssh into the machine, and query VM properties (such RAM, CPUs, etc),
• provides a simple echo service (to be able to confirm in an application-specific way that the VM is running)
  
• The service listens at a predefined port
• A user (may be hard coded) telnets into that socket
• Whichever text message the user sends will get returned (echoed) with a little server prefix (e.g. current time & server IP)
• If the user sends "EXIT" then the connection to the echo service is terminated

1. Each identified volunteer site:
2. Creates an account (for now username & password) for a test user. (Perhaps individual users for each other participating Resource Centre.)
   
3. That user need not be the same that connects to the echo service
4. Provisions the reference VM for the test user, and provides the ID for that VM.
5. Each identified volunteer site:
6. Uses a test client for their own
   
7. Start running tests against other participating Resource Providers
8. Record the results in the Wiki

Test cases

This section describes a set of agreed test cases (see below) and a set of testcases that need further discussion whether to include them or not.

Test cases that need discussion

1. Change VM attributes while the VM is active.
   I haven't found any specific information about this behaviour. I think it is useful to test, but this might go too foar for the purpose of the task force.

Agreed test cases

The following test cases have been identified as the minimal set of coverage testing the OCCI capabilities:

1. Identify and query the VM
   1. Query for a listing of compute resources.
      1. Fail if the pre-provisioned VM is not in the list.
   2. Query the pre-provisioned compute resource.
      1. Fail if it cannot be queried for detailed information.
2. Change the VM attributes
   1. Query for the VM.
      1. Fail if the instance is NOT in state 'inactive'
   2. Change the attribute occi.compute.cores to a value different than given in the query.
   3. Change the attribute occi.compute.hostname to a value different than given in the query.
   4. Change the attribute occi.compute.speed to a value different than given in the query.
   5. Change the attribute occi.compute.memory to a value different than given in the query.
   6. Query again for the compute resource.
      1. Fail if at least one attribute did not change its value.
3. Start the VM
   1. Query for the VM.
      1. Fail if it is not listed, or NOT in state inactive.
   2. Invoke the action start on the VM.
   3. Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
      1. Fail if the VM does not start up (i.e. does not arrive at state active).
   4. Connect to the Echo service and send some messages around.
      1. Fail if the echo service cannot be contacted.
4. Restart the VM
   1. Prerequisite: Test 3 succeeded (i.e. VM in state active).
   2. Invoke action restart on the VM, using the warm method.
   3. Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
      1. Fail if the VM does not start up
   4. The retrieved VM state must transition, in this order, through the states active --> inactive --> active
   5. Connect to the Echo service and send some messages around.
      1. Fail if the echo service cannot be contacted.
5. Suspend/resume the VM
   1. Prerequisite: Test 3, or Test 4 succeeded (i.e. VM in state active).
   2. Invoke action suspend on the VM, using the hibernate method.
   3. Monitor the VM state by querying for the VM.
      1. Fail if the VM does transition into state suspended.
   4. Connect to the Echo service and send some messages around.
      1. Fail if the echo service can be contacted to echo messages back.
   5. Invoke action start on the VM.
   6. Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
      1. Fail if the VM does not transition into state active.
   7. Connect to the Echo service and send some messages around.
      1. Fail if the echo service cannot be contacted.

1. Stop the VM
   1. Prerequisite: Test 3, 4 or Test 5 succeeded (i.e. VM in state active).
   2. Query for the VM.
      1. Fail if it is not listed, or NOT in state active.
   3. Connect to the Echo service and send some messages around.
   4. Invoke the action stop on the VM.
   5. Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
      1. Fail if the VM does not assume the state inactive.