Difference: VmImagePropagationNotes (1 vs. 14)

Revision 142013-11-01 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 20 to 20
 
  • This task aims to address these issues and improve the user experience when interacting with Cloud Scheduler and distributed clouds.
Changed:
<
<

Preferred solution: Stand Alone (Django) server.

>
>

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

 image-propagation-3.png

Notes:

Line: 37 to 37
 
  • 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.
Changed:
<
<
  • Interfaces: Interactively through a web browser, RESTfulAPI, client API.
>
>
  • Interfaces: Interactively through a web browser, RESTful API, client API.
 

Scenarios

Deleted:
<
<
  1. End-user creates a VM image from scratch
    1. End-user creates a new VM image on the hypervisor if his choice using the tools provided by the hypervisor (i.e., livbirt, virt-install, etc...)
    2. End-user uploads new image to a cloud:
      • Openstack:
        1. End-user source keystone creds rc file for the target cloud
        2. End-user uploads new image to OpenStack cloud via Horizon web UI or glance CLI
      • repoman:
        1. End-user creates a x509 proxy
        2. End-user uploads new image to repoman
  2. End-user runs (boots) his VM image interactively
    • Openstack:
      1. End-user source keystone creds rc file for the target cloud
      2. End-user locates his VM image via Horizon we UI or glance CLI
      3. End-user instantiates an instance of the VM image via Horizon we UI or glance CLI
    • Nimbus:
      1. End-user creates a x509 proxy
      2. End-user runs vm-run command
  3. End-user makes changes to his VM image and wants to test his changes interactively
  4. End-user wants to run jobs via the CloudScheduler using one of his VM images
  5. End-user gains access to a new cloud resource and wants to use it
  6. End-user loses access to an existing cloud resource
  7. End-user deletes one of his VM image (image not needed anymore)

or

 
  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.

Revision 132013-10-24 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 64 to 64
 
  1. End-user deletes one of his VM image (image not needed anymore)

or

Changed:
<
<
>
>
  1. What kind of authentication do we want for the service (x.509, or keystone, ldap, domain defined, other)?
 
  1. Admin creates user's login ID. Info includes ID, name, & email. Successful creation sends email to user.
  2. User creates/changes password through forgotten password dialog.
  3. User logs into Propagator.

Revision 122013-10-23 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Added:
>
>
 
Line: 19 to 20
 
  • This task aims to address these issues and improve the user experience when interacting with Cloud Scheduler and distributed clouds.
Changed:
<
<

Solutions

Below is a list of different proposed solutions to the problem.

Solution 1: Glance as main server and UI; propagate to repoman

  • Users use glance interface to store and work with their images.
  • repoman server running as is
  • external utility that will propagate images in glance to other glance servers and repoman
  • QUESTIONS:
    • how do we deal with dual hypervisor images?
    • Is there a save image hook in glance that we can use to automatically trigger propagation?
    • GSI authenticaiton when propagating to repoman servers?
      • glance server authenticates using a service certificate and sets the image owner accordingly

Solution 2: Repoman as main server and UI; propagate to glance

  • Users continue to use repoman to store and work with their images.
  • external utility that will propagate images from repoman to glance servers
  • repoman would store info about glance servers and openstack user creds
  • repoman could automatically call the external tool on image save command
    • user will get instant feedback on when propagation is done
  • how do we deal with dual hypervisor images?
    • store them as 2 separate images in glance?

Solution 3: Stand Alone (Django) server.

>
>

Preferred solution: Stand Alone (Django) server.

 image-propagation-3.png
Added:
>
>

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.
Line: 58 to 37
 
  • 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.
Added:
>
>
  • Interfaces: Interactively through a web browser, RESTfulAPI, client API.
 

Scenarios

  1. End-user creates a VM image from scratch
Line: 84 to 64
 
  1. End-user deletes one of his VM image (image not needed anymore)

or

Changed:
<
<
  • All via the web browser:
>
>
 
  1. Admin creates user's login ID. Info includes ID, name, & email. Successful creation sends email to user.
  2. User creates/changes password through forgotten password dialog.
  3. User logs into Propagator.
Line: 96 to 76
 
      • and others as required.
  1. User modifies target cloud.
  2. User deletes target cloud.
Changed:
<
<
  1. User display cloud-centric view.
  2. User display image centric view.
  3. User manually copies image to one or more locations.
>
>
  1. User displays cloud-centric view.
  2. User displays image centric view.
  3. User manually to copy an image to one or more locations.
  4. User creates template to copy an image to one or more places
  5. User creates a script to copy an image to one or more places
 
  1. User updates an image.
  2. User deletes an image.
Deleted:
<
<

Solution 4: Image propagation triggered by CloudScheduler

image-propagation-4.png

  • Instead of triggering the image propagation on image creation or save, let the CloudScheduler trigger the image propagation (if needed) each time a job is submitted.
    • Similar to solution #2 above
  • Users continue to use repoman to store and work with their images.
  • When CloudScheduler selects a cloud to boot a VM for a queued job, if first checks to see if image propagation is required. This could be made by making a call to the external propagation component. This check is done using the cloud's API. If the image is not present or outdated, then the image propagation component will copy (propagate) the VM image to that cloud's repository and then the call would return and the CloudScheduler will then boot the image.
  • CloudScheduler will select either the Xen or KVM version of the image to propagate, depending of the hypervisor type of the target cloud.
  • The propagation component will need to have a table with the user credentials for every cloud that user can submit jobs too.
  • CloudScheduler already has access to the submitting user's GSI proxy, so it is easy to also propagate to repoman servers if needed.
  • Image propagation is deferred (done only when a job needs the latest VM image) and only to the clouds that will actually run jobs using this VM image.

<--

Scenarios/Use Cases

NOTE: This section is under construction and incomplete.

For documentation purposes, let's call the image propagating background process ImageSyncer.

Glance UI

Existing image upload

  1. User already has an image, accessible via HTTP, which he would like to upload to the cloud.
  2. User logs into the OpenStack web portal and creates a new image using the web GUI and points to the image URL
  3. Image gets uploaded to the Glance server.
  4. ImageSyncer detects the new image
  5. ImageSyncer checks in its internal tables and sees that this user has access to OpenStack clouds A, B, and Nimbus cloud N. OpenStack user credentials for A and B can be found in the table. Where to get the GSI proxy for repoman server?
  6. Image Syncer notifies the user (via email) that the image has been successfully propagated to A, B and C.
  7. User then submits his/her jobs to Condor.

Repoman UI

-->

 * Back to the project page.

-- AndreCharbonneau - 2013-07-03

Revision 112013-10-21 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 84 to 84
 
  1. End-user deletes one of his VM image (image not needed anymore)

or

Changed:
<
<
  1. (User) create Propagator login ID.
>
>
  • All via the web browser:
  1. Admin creates user's login ID. Info includes ID, name, & email. Successful creation sends email to user.
  2. User creates/changes password through forgotten password dialog.
 
  1. User logs into Propagator.
  2. User defines target cloud.
    • Types of cloud supported:

Revision 102013-10-17 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Changed:
<
<
This page contains various notes for the VM Image Propagation part of the project.
>
>
 
Line: 133 to 133
  -->
Added:
>
>
* Back to the project page.
 -- AndreCharbonneau - 2013-07-03

META FILEATTACHMENT attachment="image-propagation-4.png" attr="" comment="solution 4 diagram" date="1373307604" name="image-propagation-4.png" path="image-propagation-4.png" size="55224" user="andrec" version="2"

Revision 92013-10-16 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.
Line: 83 to 83
 
  1. End-user loses access to an existing cloud resource
  2. End-user deletes one of his VM image (image not needed anymore)
Added:
>
>
or

  1. (User) create Propagator login ID.
  2. User logs into Propagator.
  3. 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.
  4. User modifies target cloud.
  5. User deletes target cloud.
  6. User display cloud-centric view.
  7. User display image centric view.
  8. User manually copies image to one or more locations.
  9. User updates an image.
  10. User deletes an image.
 

Solution 4: Image propagation triggered by CloudScheduler

image-propagation-4.png

Revision 82013-10-16 - andrec

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.
Added:
>
>
 

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.
Line: 57 to 59
 
  • 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.
Added:
>
>

Scenarios

  1. End-user creates a VM image from scratch
    1. End-user creates a new VM image on the hypervisor if his choice using the tools provided by the hypervisor (i.e., livbirt, virt-install, etc...)
    2. End-user uploads new image to a cloud:
      • Openstack:
        1. End-user source keystone creds rc file for the target cloud
        2. End-user uploads new image to OpenStack cloud via Horizon web UI or glance CLI
      • repoman:
        1. End-user creates a x509 proxy
        2. End-user uploads new image to repoman
  2. End-user runs (boots) his VM image interactively
    • Openstack:
      1. End-user source keystone creds rc file for the target cloud
      2. End-user locates his VM image via Horizon we UI or glance CLI
      3. End-user instantiates an instance of the VM image via Horizon we UI or glance CLI
    • Nimbus:
      1. End-user creates a x509 proxy
      2. End-user runs vm-run command
  3. End-user makes changes to his VM image and wants to test his changes interactively
  4. End-user wants to run jobs via the CloudScheduler using one of his VM images
  5. End-user gains access to a new cloud resource and wants to use it
  6. End-user loses access to an existing cloud resource
  7. End-user deletes one of his VM image (image not needed anymore)
 

Solution 4: Image propagation triggered by CloudScheduler

image-propagation-4.png

Revision 72013-10-11 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.
Line: 41 to 41
 
  • how do we deal with dual hypervisor images?
    • store them as 2 separate images in glance?
Changed:
<
<

Solution 3: Stand Alone Django server.

TODO (Colin)
  • Database keeps track of image pro
>
>

Solution 3: Stand Alone (Django) server.

image-propagation-3.png
  • 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.
 

Solution 4: Image propagation triggered by CloudScheduler

image-propagation-4.png
Line: 80 to 92
 -- AndreCharbonneau - 2013-07-03

META FILEATTACHMENT attachment="image-propagation-4.png" attr="" comment="solution 4 diagram" date="1373307604" name="image-propagation-4.png" path="image-propagation-4.png" size="55224" user="andrec" version="2"
Added:
>
>
META FILEATTACHMENT attachment="image-propagation-3.png" attr="" comment="" date="1381532559" name="image-propagation-3.png" path="image-propagation-3.png" size="184720" user="crlb" version="2"

Revision 62013-07-08 - andrec

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.
Line: 45 to 45
 TODO (Colin)
  • Database keeps track of image pro
Changed:
<
<

Solution 4: Image propagation implemented in CloudScheduler

  • Instead of implementing a separate component to do the propagation, the propagation code is added to the CloudScheduler, to be triggered each time a job is submitted.
>
>

Solution 4: Image propagation triggered by CloudScheduler

image-propagation-4.png

  • Instead of triggering the image propagation on image creation or save, let the CloudScheduler trigger the image propagation (if needed) each time a job is submitted.
    • Similar to solution #2 above
 
  • Users continue to use repoman to store and work with their images.
Changed:
<
<
  • When CloudScheduler selects a cloud to boot a VM for a queued job, if first checks to see if that particular cloud's image repository has the latest version of the required VM image. This check is done using the cloud's API. If the image is not present or outdated, then the CloudScheduler will copy (propagate) the VM image to that cloud's repository and then boot the image.
>
>
  • When CloudScheduler selects a cloud to boot a VM for a queued job, if first checks to see if image propagation is required. This could be made by making a call to the external propagation component. This check is done using the cloud's API. If the image is not present or outdated, then the image propagation component will copy (propagate) the VM image to that cloud's repository and then the call would return and the CloudScheduler will then boot the image.
 
  • CloudScheduler will select either the Xen or KVM version of the image to propagate, depending of the hypervisor type of the target cloud.
Changed:
<
<
  • CloudScheduler will need to have a table with the user credentials for every cloud that user can submit jobs too.
>
>
  • The propagation component will need to have a table with the user credentials for every cloud that user can submit jobs too.
 
  • CloudScheduler already has access to the submitting user's GSI proxy, so it is easy to also propagate to repoman servers if needed.
  • Image propagation is deferred (done only when a job needs the latest VM image) and only to the clouds that will actually run jobs using this VM image.
Line: 75 to 78
 -->

-- AndreCharbonneau - 2013-07-03

Added:
>
>
META FILEATTACHMENT attachment="image-propagation-4.png" attr="" comment="solution 4 diagram" date="1373307604" name="image-propagation-4.png" path="image-propagation-4.png" size="55224" user="andrec" version="2"

Revision 52013-07-07 - andrec

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.
Line: 10 to 10
 
    • 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.
Changed:
<
<
    • GSI authentication
>
>
    • 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.
Line: 25 to 25
 
  • Users use glance interface to store and work with their images.
  • repoman server running as is
  • external utility that will propagate images in glance to other glance servers and repoman
Added:
>
>
  • QUESTIONS:
 
  • how do we deal with dual hypervisor images?
  • Is there a save image hook in glance that we can use to automatically trigger propagation?
Changed:
<
<
  • GSI authenticaiton?
>
>
    • GSI authenticaiton when propagating to repoman servers?
      • glance server authenticates using a service certificate and sets the image owner accordingly
 

Solution 2: Repoman as main server and UI; propagate to glance

  • Users continue to use repoman to store and work with their images.
  • external utility that will propagate images from repoman to glance servers
Changed:
<
<
  • repoman could store info about glance servers and openstack user creds
>
>
  • repoman would store info about glance servers and openstack user creds
 
  • repoman could automatically call the external tool on image save command
Added:
>
>
    • user will get instant feedback on when propagation is done
 
  • how do we deal with dual hypervisor images?
Changed:
<
<
  • Keystone authentication?
>
>
    • store them as 2 separate images in glance?
 

Solution 3: Stand Alone Django server.

Added:
>
>
TODO (Colin)
 
  • Database keeps track of image pro
Added:
>
>

Solution 4: Image propagation implemented in CloudScheduler

  • Instead of implementing a separate component to do the propagation, the propagation code is added to the CloudScheduler, to be triggered each time a job is submitted.
  • Users continue to use repoman to store and work with their images.
  • When CloudScheduler selects a cloud to boot a VM for a queued job, if first checks to see if that particular cloud's image repository has the latest version of the required VM image. This check is done using the cloud's API. If the image is not present or outdated, then the CloudScheduler will copy (propagate) the VM image to that cloud's repository and then boot the image.
  • CloudScheduler will select either the Xen or KVM version of the image to propagate, depending of the hypervisor type of the target cloud.
  • CloudScheduler will need to have a table with the user credentials for every cloud that user can submit jobs too.
  • CloudScheduler already has access to the submitting user's GSI proxy, so it is easy to also propagate to repoman servers if needed.
  • Image propagation is deferred (done only when a job needs the latest VM image) and only to the clouds that will actually run jobs using this VM image.

 -- AndreCharbonneau - 2013-07-03

Revision 42013-07-05 - andrec

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.
Line: 10 to 10
 
    • 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.
Added:
>
>
    • GSI 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.
Changed:
<
<
TODO
>
>
 

Solutions

Below is a list of different proposed solutions to the problem.
Line: 40 to 41
 

Solution 3: Stand Alone Django server.

  • Database keeps track of image pro
Added:
>
>

Scenarios/Use Cases

NOTE: This section is under construction and incomplete.

For documentation purposes, let's call the image propagating background process ImageSyncer.

Glance UI

Existing image upload

  1. User already has an image, accessible via HTTP, which he would like to upload to the cloud.
  2. User logs into the OpenStack web portal and creates a new image using the web GUI and points to the image URL
  3. Image gets uploaded to the Glance server.
  4. ImageSyncer detects the new image
  5. ImageSyncer checks in its internal tables and sees that this user has access to OpenStack clouds A, B, and Nimbus cloud N. OpenStack user credentials for A and B can be found in the table. Where to get the GSI proxy for repoman server?
  6. Image Syncer notifies the user (via email) that the image has been successfully propagated to A, B and C.
  7. User then submits his/her jobs to Condor.
 
Added:
>
>

Repoman UI

  -- AndreCharbonneau - 2013-07-03 \ No newline at end of file

Revision 32013-07-04 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.

Problem description

Added:
>
>
  • 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.
  • 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.
 TODO

Solutions

Revision 22013-07-03 - crlb

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.
Line: 26 to 26
 
  • how do we deal with dual hypervisor images?
  • Keystone authentication?
Changed:
<
<

Scenario 3: ???

>
>

Solution 3: Stand Alone Django server.

  • Database keeps track of image pro
 

Revision 12013-07-03 - andrec

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="WebHome"
This page contains various notes for the VM Image Propagation part of the project.

Problem description

TODO

Solutions

Below is a list of different proposed solutions to the problem.

Solution 1: Glance as main server and UI; propagate to repoman

  • Users use glance interface to store and work with their images.
  • repoman server running as is
  • external utility that will propagate images in glance to other glance servers and repoman
  • how do we deal with dual hypervisor images?
  • Is there a save image hook in glance that we can use to automatically trigger propagation?
  • GSI authenticaiton?

Solution 2: Repoman as main server and UI; propagate to glance

  • Users continue to use repoman to store and work with their images.
  • external utility that will propagate images from repoman to glance servers
  • repoman could store info about glance servers and openstack user creds
  • repoman could automatically call the external tool on image save command
  • how do we deal with dual hypervisor images?
  • Keystone authentication?

Scenario 3: ???

-- AndreCharbonneau - 2013-07-03

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback