• Back to the project page.
• The four solutions version of this page (rev=11).

Problem description

• Cloud Scheduler development began in 2009. At that time the most mature, robust IaaS web service was implemented via Nimbus.
• Nimbus provided an http adapter for the propagation of VM images enabling the use of one or more remote image repositories ideal for the distributed cloud model implemented via Cloud Scheduler.
• To aid the end user in the management of VM images, an image repository manager, Repoman, was developed. This repository manager provided the following features:
  • Allowed remote (http/https) propagation.
  • Managed dual-hypervisor VM images (images that can run under both KVM and Xen hypervisors).
  • Allowed users to create, update, instantiate, share, and delete images.
  • Maintained metadata about images which could be viewed or modified by the user.
  • GSI (x509) authentication
• With the ascendancy of other IaaS middleware solutions with dedicated, institutional image repositories (EC2, Openstack, etc.), the burden of image management is placed once again on the end user. Specifically burdensome to users of the distributed cloud model is:
  • The uploading of images to the individual repositories for each non-Nimbus, distributed cloud.
  • The selection and management of the VM kernel in a multi-hypervisor environment.
• This task aims to address these issues and improve the user experience when interacting with Cloud Scheduler and distributed clouds.

Preferred solution: Stand Alone (Django as per OpenSack dashboard) server.

Notes:

• The "?" indicates other cloud types as required.
• Black arrows signify http/https propagation for instantiation.
• Red arrows indicate bi-directional propagation/conversion between repositories.
• Propagator uses:
  • Repoman client to mange interactions with the repoman server.
  • The glance and nova clients to manage interactions with OpenStack clouds.
  • Web framework facilites and linux utilities to manage interactions with end user systems and workstations.
• It is the user's responsibility to create the content within the image, including single/dual hypervisor requirements.
• Image propagation may be initiated interactively or be scripted via RESTful API. Alternatively, propagation could be initiated by user defined templates.
• Propagator will automate image copying and conversion (image to qcow2, kvm to xen, etc.) and manage user credentials.
• Propagator should refuse to do anything (and say why) on any error (ie. duplicate names, xen only image to kvm only cloud, bad credentials on a participating repository, etc.)
• Images should managed and executed by name.
• The system does not require that a repository be designated as the master, ie. in the diagram, if the second openstack cloud requires image A, then it could be copied from either the glance or the repoman repository.
• Interfaces: Interactively through a web browser, RESTful API, client API.

Scenarios

1. What kind of authentication do we want for the service (x.509, or keystone, ldap, domain defined, other)?
2. Admin creates user's login ID. Info includes ID, name, & email. Successful creation sends email to user.
3. User creates/changes password through forgotten password dialog.
4. User logs into Propagator.
5. User defines target cloud.
   • Types of cloud supported:
     • Repoman: x509 (myproxy id/password), URL, repoman ID
     • Glance: OpenStack RC file and password.
     • Linux Desktop Cloud: fqdn, id, ssl pub key.
     • and others as required.
6. User modifies target cloud.
7. User deletes target cloud.
8. User displays cloud-centric view.
9. User displays image centric view.
10. User manually to copy an image to one or more locations.
11. User creates template to copy an image to one or more places
12. User creates a script to copy an image to one or more places
13. User updates an image.
14. User deletes an image.

* Back to the project page.

-- AndreCharbonneau - 2013-07-03