16.2 Standards for IaaS interoperability
18.1.3 Entities Representation System
The core of the entities representation system is the Resource type and includes also the Entity, Link and Action types. A Resource is anything that can be inspected and manipulated in the
underlying infrastructure of the IP such as a virtual machine (compute) or a disk (storage). In particular, there are four resource types: Compute, OPTIMIS Compute, Network and Storage. Resources can be connected through the Link type.
Resources and Links can have Actions through their Kind. Actions are basically operations which can be invoked on resources. The Action type itself is an abstract type and it must be sub-typed for any specific Action that a resource can have. The parameters of an Action are exposed through its attributes and, consequently, through the attributes attribute of the identifying Category. Figure 18.4 shows all the actions defined in the standard. More actions could be added to perform additional operations, for instance, it may be reasonable to add “resize” operations to other resources different from storage. A resize operation in the compute type could change its memory or CPU speed in order to make VMs elastic and to achieve better scalability.
The following sections describe each type of resource in detail and their actions.
Action Stop - method: STOP_METHOD Start Restart - method: RESTART_METHOD Suspend - method: SUSPEND_METHOD
Start Stop Online
Offline Snapshot
Backup Resize
- size: Float
Compute Actions Network Actions Storage Actions
GRACEFULL ACPIOFF POWEROFF <<enumeration>> STOP_METHOD GRACEFULL WARM COLD <<enumeration>> RESTART_METHOD HIBERNATE SUSPEND <<enumeration>> SUSPEND_METHOD
Diagram 18.4: Actions defined in the OCCI standard. More actions can be added by providers to represent provider-specific operations
Compute (Virtual Machine)
This type represents an information processing resource, which in this project will only be a Virtual Machine. There are four operations which can be invoked on compute instances, all of them are used to change the state of the machine (see Figure 18.1) as well as to perform any operations derived from this change in state. Table 18.2 shows the resulting state for each operation.
In addition to the changes of state shown, a Virtual Machine can be deleted at any time, in which case its resources would be freed completely.
Figure 18.1: Compute type state diagram, where state changes correspond to actions
Action Target State
start active
stop inactive
restart active (via start and stop chain)
suspend suspended
Table 18.2: Changes of state performed by Compute actions
OPTIMIS Compute
This is a custom type that augments the capabilities of the compute type in order to be compliant with the OPTIMIS requirements. Specifically it adds to attributes:
• service_id:Defines the service running on a VM.
• image: Defines the image of the disk that will be attached to the VM.
When OPTIMIS deploys a new VM it specifies whichservice(job, task, program, etc.) will run on it. There can be several VMs running the same service. Moreover, in some cases, OPTIMIS needs to attach disks to these VMs.
Network
This type represents a low level networking resource, such as a virtual switch. There are two operations which can be invoked on network instances which are used to perform state changes (see figure 18.2). Table 18.3 shows the resulting state for each operation.
Additionally, the IPNetowrking mixin is included in order to extend network resources with IP related capabilities. The IPNetworking mixin is assigned the scheme of “http://schemas.ogf.org- /occi/infrastructure/network#” and theterm “ipnetwork”. Its attributes are described in table 18.4
With the combination of the Network resource and the IPNetworking mixin, the location of a VM within a network can be fully represented.
Figure 18.2: Network type state diagram, where state changes correspond to actions
Action Target State
start active
stop inactive
Table 18.3: Changes of state performed by Network actions
Attribute Type Description
address IPv4 or IPv6 address range IP Network Address (e. g. 192.168.0.1/24)
gateway IPv4 or IPv6 address IP Network Address gateway (e. g. 192.168.0.1)
allocation dynamic, static Address allocation mechanism: dynamic uses DHCP
while static uses supplied static network configura- tions.
Table 18.4: IPNetworkingMixin attributes
Storage
This type represents a resource that records information to a data storage device. There are six operations invocable on storage resources which are used to perform state changes (see figure 18.3). Table 18.5 shows the resulting state for each operation.
Figure 18.3: Storage type state diagram, where state changes correspond to actions
Action Target State
online online offline offline backup backup snapshot snapshot resize resize degrade degarded
Table 18.5: Changes of state performed by Storage actions
Network Interface
This link sub-type represents a network client device, such as a network adapter, that is, it’s a link between a compute resource and a network resource. It has the same operations and states that the Network resource.
In a similar way to the Network resource, this link type is extended through the IPNetwork- Interface mixin which provides IP capabilities to a network interface. It has the same attributes as the IPNetwork mixin.
Storage Link
This link sub-type represents a connection between a Resource (usually a Compute resource) and a Storage device. Figure 18.4 illustrates the state diagram of a StorageLink instance. It has the same operations and states than the Network resource.
Figure 18.4: Storage Link type state diagram
Monitoring Mixin
Currently, the OCCI-WG is working on a draft1for a Monitoring extension for OCCI. Despite
that the extension is still very incomplete it already provides some guidelines on how such an
extension should be done.
The extension defines a genericmetricmixin object with the attributes shown in table 18.6.
Attribute Value
term Metric
scheme http://schemas.ogf.org/occi/monitoring#
title A metric mixin
attributes
Attribute Type Multiplicity Description
value String 1 Value of the metric being monitored
timestamp String 1 Time of the last calculation on the
metric
samplerate Float 0..1 Rate at which the metric is calcu-
lated
resolution String 0..1 Indicates the multiple or fraction of
the unit2
Table 18.6: Monitoring mixin attributes
Having this mixin as a base, any number of OPTIMIS –specific metrics can be created in form of mixins related to it. This way, two mixins are defined:
• used_cpu_metric:
– Title: cpu.used
– Term: used
– Scheme: [service_scheme_url]/metric/compute/cpu#
– Related: metric mixin
• used_mem_metric:
– Title: mem.used
– Term: used
– Scheme: [service_scheme_url]/metric/compute/mem#
– Related: metric mixin
This document presents the design of how monitoring could be implemented following the OCCI standard. However, since the monitoring process in Arsys deals with some legacy appli- cations and methods, it would be very costly to re-implement. Therefore, for the moment, the monitoring function will be achieved using the legacy web service.
18.2
Behavioral Model
The Arsys RESTful web service exposes a set of operations accessible through the GET, POST, PUT and DELETE HTTP verbs. The OCCI model defines a fairly big amount of operations,
since it is designed to fit in any platform, but the Arsys web service will only implement the operations required by OPTIMIS, leaving the door open for future extensions derived from changes in the OPTIMIS requirements. In particular, OCCI includes a set of query and dis- covery methods that can be used to discover and navigate through the providers’ resources and get information about the features and capabilities of the provider. These operations are not implemented since the only client accessing the service is OPTIMIS.
As said in the previous section, monitoring in the Arsys service will be done using the legacy service. However, this document still shows the design of an OCCI compliant imple- mentation of the monitoring methods in order to have a clearer picture of how a complete OCCI compliant solution could be implemented.
The main resource that is handled by the web service is the OPTIMIS Compute resource which represents a Virtual Machine used by OPTIMIS. Virtual Machines are organized in a hi- erarchical way, where running services are the parents and VMs the children, and are accessible through the /{service_id}/{vm_name} URL (see figure 18.5 for an example).
service_1 vm2 vm1 service_2 vm1 runs runs runs
/service_1/vm1 /service_1/vm2 /service_2/vm1
Figure 18.5: Example of the URL name-space hierarchy
Table 18.7 shows the operations that will be implemented on the service. Below there is a description of each of the methods exposed.
Name Verb Path Description
Create VM POST /optimis_compute/ Creates a new Virtual Machine ac-
cording to the information provided in the request body.
Delete VM DELETE /vms/{service_id}-
/{vm_name}
Deletes the vm_name Virtual Ma- chine running the service_id ser- vice.
Update VM PUT/POST /vms/{service_id}-
/{vm_name}
Updates the vm_name Vitual Ma- chine’s attributes (memory, cpu speed, . . . ) running the service_id
service with the information pro- vided in the request body
Execute action POST /vms/{service_id}-
/{vm_name}- ?action={action- _name}
Performs action on the vm_name
Virtual Machine running the ser-
vice_idservice.
Get VM GET /vms/{service_id}-
/{vm_name}- ?monitoring=[0/1]
Get information about thevm_name
Virtual Machine running the ser-
vice_id service. Also retrieves its
monitoring data if the monitoring parameter is set to 1.
Get Service VMs GET /vms/{service_id}-
?monitoring=[0/1]
Returns information (status, IP ad- dress) about the VMs running the
service_idservice. The monitoring
parameter specifies whether moni- toring data should also be retrieved.
Get all VMs GET /vms-
?monitoring=[0/1]
Returns information (status, IP ad- dress) about all OPTIMIS VMs. The monitoring parameter speci- fies whether monitoring data should also be retrieved.
Terminate Service
DELETE /vms/{service_id} Removes all VMs running the ser-
vice_id service and frees every IP
assigned to the VMs. Table 18.7: Methods exposed by the service
18.2.1
Authentication
Authentication with the server will be done through the pass of credentials (username and password). Every call made to the web service will contain the username and the password encoded in the header of the request, specifically it will be passed in the standard header field “Authorization”3 . The value passed in this field will be the string “[username]:[password]”, encoded as a base64 string in order to protect its confidentiality.
The following example illustrates the headers of a request made by the username: optimis
with the passwordsecret:
> Content-type: text/plain > Accept: text/plain
> Authorization: bXl1c2VyOnNlY3JldA== > [...]