The Unified Interface for Real-world Cloud Service Access and Manipulation Tasks

The above cloud service specification case studies suggest that SAMOS framework can adequately model and specify the variety of service operations from distinct service types, delivery models and provider clouds. Based on these specifications, USAMS prototype is implemented to enable a unified interface for comprehensive cloud service management tasks. This section demonstrates some case studies on cloud service access and manipulation tasks by utilising a real-life IaaS service (AWS EC2).

Table 7.12 Rackspace Cloud Load Balancers Provider-Specific Operation Specification Granular

Service Instance Node Operations

Rackspace Cloud Load Balancer Instance Node

Type SRPreCondition SRParameter/SRSubject SROutcome SRPostCondition

Get LoadBalancer Instance Node IP

SIR Load Balancer is in “ACTIVE” state Rackspace CloudLoadBalancer InstanceNodeID(M) Rackspace Cloud LoadBalancer InstanceNodeIP Unconditional Get LoadBalancer Instance Node Status

SIR Load Balancer is in “ACTIVE” state Rackspace CloudLoadBalancer InstanceNodeID(M) Rackspace Cloud LoadBalancer InstanceNode Condition Unconditional Get LoadBalancer Instance Node Port

SIR Load Balancer is in “ACTIVE” state Rackspace CloudLoadBalancer InstanceNodeID(M) Rackspace Cloud LoadBalancer InstanceNode Port Unconditional Edit LoadBalancer Instance Node Weight SMR Load Balancer is in “ACTIVE” state Rackspace CloudLoadBalancer InstanceNodeID(M), Rackspace CloudLoadBalancer InstanceNodeWeight(M) Operation Succeeded Load Balancer is in “ACTIVE” state Edit LoadBalancer Instance Node Status SMR Load Balancer is in “ACTIVE” state Rackspace CloudLoadBalancer InstanceNodeID(M), RackspaceCloud LoadBalancerInstance NodeCondition(M) Operation Succeeded Load Balancer is in “ACTIVE” state Delete Load Balancer Instance Node SMR Load Balancer is in “ACTIVE” state Rackspace CloudLoadBalancer InstanceNodeID(M) Operation Succeeded Load Balancer is in “ACTIVE” state …

139

USAMS adopts a structured interface for cloud service operation retrieval preparation and execution. Basically, all cloud services, CSIs and PSSAs are initially displayed in a small panel. Seen in Figure 7.10, the panel comprises four buttons: “Description”, “Use Entity”, “Information” and “Manipulation”. By clicking the “Description”, users can view its annotation description through platform sub system interactions. The “Information” and “Manipulation” buttons lead to the respected SIR and SMR operations, which are retrieved dynamically from CSAMO. Then, if a user’s API account authorisation permits, one can execute the respected operations via the interface.

Figure 7.10 Initial Cloud Service Entity Panels

7.2.3.1 Cloud Service Access Operations

Using AWS EC2 as the example cloud service, the following contents demonstrate the processes of the SIR operations retrieval, followed by real-time service and service instance accesses tasks. To illustrate the practical service access example, Figure 7.11 demonstrates the appearance of cloud service SIR operation retrieval. In fact, as the “Information” button is clicked, a dynamic ontology lookup is performed, where the relevant SIR operations specifications are extracted, processed and displayed for further commands. As a typical IaaS compute service, EC2 is provisioned with various service operations which are closely relevant to VM configuration tasks: sizes, access keys, security groups, regions, etc. Further, while acquiring the SIR option lists, each operation would

140

be mapped with a specific API call for execution preparation. Once the preparation is ready, a “Request” button will be presented next the operations, notifying the user that one can request the information through pre mapped service programming calls.

Figure 7.11 EC2 SIR Operations Retrieval

Then, as the user clicks the “Request” button, relevant pre-mapped API calls are dynamically initiated. If the requests successfully execute, the respected service data is obtained from the service provider (i.e. AWS EC2) via the API requests (See Figure 7.12). For instance, EC2 involves several aspects that are relevant to the usage of VMs: VM sizes, images, security groups, regions, etc. All of the information can be acquired via the SIR execution. Additionally, via the “has instance” operation, the user can retrieve the VM instances owned for a specific region.

141

Figure 7.12 EC2 SIR Operation with Real-time Cloud Data Access

Subsequently, for the dynamically retrieved service information, there can be additional actions, if the entity type allows. As previously discussed, all CSIs and PSSAs are backed by subsequent actions which are uniquely presented, owning to their specific characteristics and usages. As shown in Figure 7.13, the “i-b2485df8” instance provides an example of SIR interaction across service and CSI levels. While the instance’s SIR operations successfully execute, the instance-specific information is then acquired from EC2. Later, based on the entity type of the newly obtained instance data (entity), they may also lead to their own lists of service request operations.

142

Figure 7.13 EC2 Instance Cloud Service SIR Interactions

In the meantime, another use of the dynamically retrieved service information (SROutcome) is known entity reuse. In this example, except the “running” status of the EC2 instance (which is unusable), all other information can be selected as either SRSubject or SRParameter or both for relevant service operations (e.g. the IP address can be used for another service; the access key can be used to create another instance).

143

7.2.3.2 Cloud Service Manipulation Operations

Figure 7.14 EC2 SMR Operation Retrieval

Continuing with the above example IaaS service, SMR operations of EC2 can also be retrieved from the operation specification ontology. Displayed in Figure 7.14, this involves a series of general service instance configuration operations (e.g. create, start, stop and terminate), plus some management operations for its unique PSSA entities (e.g. EC2 KeyPair, SecurityGroup). As a user clicks at an operation command, an ontology look up process would be triggered, where the respected SRParameter requirements will be obtained and displayed along with the SMR. Shown in Figure 7.14, for instance, “set region” command would need the user to specify a relevant “EC2 Region”; “create security group” would require an input of “EC2 Security Group Name” and “EC2 Security Group Description”.

144

Figure 7.15 EC2 SMR Operation Preparation

To further explain how SMR operation is prepared and executed, a detailed example is given, using the “create new VMs” operation. The example SMR requires a number of parameters including “EC2 Region”, “EC2 Instance Type”, “EC2 AMI ID”, etc. As illustrated in Figure 7.15, these parameters can be entered through either selection of the previously obtained service information, or manual typed input. As the system detects user’s input, fulfilled parameters would fit into the respected position whilst the icon followed which would transit from “unchecked” into “checked”. By the time all of the SRParameters are fulfilled, a dynamic service condition checking process is initiated prior to the operation execution. In this case, the command requires the user to own no more than 20 instances per region.

145

Figure 7.16 EC2 SMR Execution

Then, as all defined requirements are fulfilled, when the user clicks the SMR command, the pre-mapped API request is sent to the service provider. After some time, relevant respond will be returned from the provider, notifying the execution status. As shown in Figure 7.16, the request has executed successfully and has resulted two newly created VM instances: “i-00cbf742”

146

and “i-01cbf743”, which can be found at the bottom the panel. Subsequently, seen in Figure 7.17, the two new instances can be found through SIR updates.

147

7.2.4 Cloud Service Operation Assistance and Dynamic