|
|
| (145 intermediate revisions by 9 users not shown) |
| Line 1: |
Line 1: |
| {{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}
| | #REDIRECT[[Federated_Cloud_VM_Management]] |
| | |
| {{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}
| |
| | |
| = Scenario 1: Running a pre-defined VM Image =
| |
| | |
| <font color="red">Leader: Michel Drescher, EGI; Matteo Turilli, Oxford e-Research Centre</font>
| |
| | |
| == Issues to follow-up/resolve ==
| |
| | |
| Following need to be considered with this scenario
| |
| | |
| #Trust level and Auditing of the VM (since it has to run as Root access) | |
| #Different VMs needed based on underlying Infrastructure such as 64 vs 32bits Or VT enabled plus Xen vs KVM
| |
| #Contextualization i.e. how users should login to this vm , how his public key transfer and active to login as root to this vm
| |
| #Which libraries/versions/compilers will be installed by default?
| |
| | |
| From a user perspective (WeNMR contribution) we would like to:
| |
| | |
| #Be able to install software on the pre-defined VM images (under the user account)
| |
| #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)
| |
| | |
| <br>
| |
| | |
| '''''Note:'''''<i>This section is heavily in-flux so the information given above might be slightly outdated. The minutes of the conference calls contain more information.</i>
| |
| | |
| == 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
| |
| | |
| #Use a reference VM that <br>
| |
| | |
| *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)<br>
| |
| *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
| |
| | |
| #Each identified volunteer site:
| |
| #Creates an account (for now username & password) for a test user. (Perhaps individual users for each other participating Resource Centre.)<br>
| |
| #That user need not be the same that connects to the echo service
| |
| #Provisions the reference VM for the test user, and provides the ID for that VM.
| |
| #Each identified volunteer site:
| |
| #Uses a test client for their own<br>
| |
| #Start running tests against other participating Resource Providers
| |
| #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 ====
| |
| | |
| #'''Change VM attributes while the VM is active.'''<br>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:
| |
| | |
| #'''Identify and query the VM'''
| |
| ##Query for a listing of compute resources.
| |
| ###Fail if the pre-provisioned VM is not in the list.
| |
| ##Query the pre-provisioned compute resource.
| |
| ###Fail if it cannot be queried for detailed information.
| |
| #'''Change the VM attributes'''
| |
| ##Query for the VM.
| |
| ###Fail if the instance is NOT in state 'inactive'
| |
| ##Change the attribute ''occi.compute.cores'' to a value different than given in the query.
| |
| ##Change the attribute ''occi.compute.hostname'' to a value different than given in the query.
| |
| ##Change the attribute ''occi.compute.speed'' to a value different than given in the query.
| |
| ##Change the attribute ''occi.compute.memory'' to a value different than given in the query.
| |
| ##Query again for the compute resource.
| |
| ###Fail if at least one attribute <u>did not</u> change its value.
| |
| #'''Start the VM'''
| |
| ##Query for the VM.
| |
| ###Fail if it is not listed, or NOT in state ''inactive''.
| |
| ##Invoke the action ''start'' on the VM.
| |
| ##Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
| |
| ###Fail if the VM does not start up (i.e. does not arrive at state ''active'').
| |
| ##Connect to the Echo service and send some messages around.
| |
| ###Fail if the echo service cannot be contacted.
| |
| #'''Restart the VM'''
| |
| ##<u>Prerequisite:</u> Test 3 succeeded (i.e. VM in state ''active'').
| |
| ##Invoke action ''restart'' on the VM, using the ''warm'' method.
| |
| ##Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
| |
| ###Fail if the VM does not start up
| |
| ##The retrieved VM state must transition, in this order, through the states ''active'' --> ''inactive'' --> ''active''
| |
| ##Connect to the Echo service and send some messages around.
| |
| ###Fail if the echo service cannot be contacted.
| |
| #'''Suspend/resume the VM'''
| |
| ##<u>Prerequisite:</u> Test 3, or Test 4 succeeded (i.e. VM in state ''active'').
| |
| ##Invoke action ''suspend'' on the VM, using the ''hibernate'' method.
| |
| ##Monitor the VM state by querying for the VM.
| |
| ###Fail if the VM does transition into state ''suspended''.
| |
| ##Connect to the Echo service and send some messages around.
| |
| ###Fail if the echo service can be contacted to echo messages back.
| |
| ##Invoke action ''start'' on the VM.
| |
| ##Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
| |
| ###Fail if the VM does not transition into state ''active''.
| |
| ##Connect to the Echo service and send some messages around.
| |
| ###Fail if the echo service cannot be contacted.
| |
| | |
| #'''Stop the VM'''
| |
| ##<u>Prerequisite:</u> Test 3, 4 or Test 5 succeeded (i.e. VM in state ''active'').
| |
| ##Query for the VM.
| |
| ###Fail if it is not listed, or NOT in state ''active''.
| |
| ##Connect to the Echo service and send some messages around.
| |
| ##Invoke the action ''stop'' on the VM.
| |
| ##Monitor the VM state by querying for the VM AND trying to connect to the VM (ping, or using the Echo service).
| |
| ###Fail if the VM does not assume the state ''inactive''.
| |
The wiki is deprecated and due to be decommissioned by the end of September 2022.