This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManagerToControlOfLifecycleOfServicesInTheCloud at Sun, 06 Nov 2022 12:21:07 GMT SourceForge : View Wiki Page: ServiceManagerToControlOfLifecycleOfServicesInTheCloud

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin

Web Site
Search Wiki Pages Project: occi-wg     Wiki > ServiceManagerToControlOfLifecycleOfServicesInTheCloud > View Wiki Page
wiki2143: ServiceManagerToControlOfLifecycleOfServicesInTheCloud
  • Name: Service Manager (RESERVOIR)
  • Contact: Luis Rodero-Merino (Telefónica I+D)
  • Type of Organization: Industry and Research
  • Description: This use case is based in the 'Service Manager' (SM) layer of the RESERVOIR project architecture. 'Service Providers' (SP) willing to deploy their service on the Cloud use this layer to control the service lifecycle. The SM operates over the Cloud infrastructure automatically as the service demands. In a way, the SM maps the service configuration and needs to calls to the Cloud infrastructure, so many of the requirements imposed by the SM are due to the flexibility that the SM aims to provide to SPs.
  • Functional Requirements:
    • Network Management: There should be methods for the Allocation of private networks, where VMs can be attached to. A special network (e.g. 'Public Network') should be available. When some network interface is attached to it, the infrastructure must assign it a public IP address.
    • Image Management: There should be methods to register, upload, update and download disk images.
    • VM Description: It should be possible to describe all the VM hardware components and their attributes, along with any restriction regarding the VM location:
      • Memory: Size
      • CPU: Architecture, amount of CPU's, speed.
      • Disk: Size, Interface (SCSI, IDE, SATA...), RAID (yes/no, and RAID level). Disk image to mount. Automatic backup (yes/no, backups frequency...).
      • Network: Interfaces, for each interface its bandwidth, and Network they are attached to.
      • Geographical restrictions: Location(s) where the VM can/cannot be deployed (for example for legal purposes).
      • Migration allowed (yes/no): If migration is supported by the infrastructure, this flag sets if it is allowed for the VM.
    • VM Management: There should be methods to allow the SM to change the VM state (for example, from ACTIVE to SUSPENDED), if such transition is allowed by the infrastructure (i.e. is defined in the OCCI's State Machine). The description of a VM can be changed when the machine is running (ACTIVE, SUSPENDED...). But it will not be taken into account until the machine is stopped and started again, unless it is a change regarding geographical or migration restrictions. Each disk backup will have an id, as the images defined by the SM. Methods to download any backup should be provided. As each backup is, after all, a disk image, it should be possible to mount it on any VM. For example, it should be possible to stop a VM, change its configuration so its disk mounts this backup image, and restart the VM.
    • Monitoring: The status (We use the term 'status' when talking about monitoring, and try not to use the term 'state' to avoid confusion with the states of the OCCI State Machine.) representation of any element is given as a list of keys and their values. For example, the status of a memory component could be given by the amount of memory used and the cache memory. Then, the keys could be 'used' and 'cache', and their values '142MB' and '430MB'. Both the request and the reply use the corresponding element identifier. Two types of monitoring should be supported:
      • Pull based: The SM can request the status of any element it has registered: VMs, networks... Also, the SM can request the status of components, for example, the status of certain disk of a certain VM.
      • Publish/subscribe based: The SM can subscribe to be notified about events on the VMs and/or Networks. Some of the events to be notified are:
        • Errors on some component of a VM.
        • Changes on the state of a VM (e.g. from ACTIVE to SUSPENDED).
        • Periodic notifications about some element state. The frequency of this notifications can be configured in the subscription message.
    • Error messages:If some VM could not be created, or some image could not be uploaded, etc... the platform should return an error message carrying a detailed description of the reason.
    • Identifications:Networks, VMs and images should have unique IDs, (UUIDs, URIs, or the like). It is to be determined whether components of VMs (disks, memory...) should have an unique ID too. IDs are assigned by the Cloud infrastructure when the corresponding element is created.
  • Non-functional Requirements:
    • Both for hardware configuration and monitoring values there should be a clear, standard way to set which magnitude the value represents. For example, when setting the memory size to '2', it must be clear that we refer to GBs and not to MBs. An option would be setting the value to '2GB', another would be allowing to set both the value and the magnitude: value '2' and magnitude 'GB'.
    • Protocols: The transport, message format, and state representation should use open and standard protocols, each one which strong software support (i.e. libraries and frameworks available for several programming languages).
 




The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManagerToControlOfLifecycleOfServicesInTheCloud at Sun, 06 Nov 2022 12:21:10 GMT