Feature #200
Image Repository
| Status: | Closed | Start date: | 03/04/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Tino Vázquez | % Done: | 100% | |
| Category: | Core & System | |||
| Target version: | Release 2.0 | |||
| Resolution: | Pull request: |
Description
The images for VM's disks are defined with the SOURCE attribute of the DISK template variable. This SOURCE is a URL, usually a file or a logical volume device, which is subsequently handled by the Transfer Manager. This generic approach has some drawbacks:
- The user has to define (and have to be aware of) the rest of the DISK attributes. For example the target device for the DISK.
- Files are handled by OpenNebula using the oneadmin identity. This makes difficult to enforce access policies for the images (e.g. define ACLs)
This campaign aims to develop an image repository for OpenNebula, description:
- The image repository will keep a logical mapping a high level description of an image disk and its physical location and configuration parameters. Example
"Ubuntu Karmic" --> /srv/cloud/images/ubuntu.img, file, sda1 "Windows Installation Disk" --> /srv/cloud/isos/winxp.iso, cdrom, hdb
- Each image can have an ACL defined. So OpenNebula can enforce access policies to a given image
- VM DISKS can be defined using the repository either by its description or using an ID, example:
NAME=my_vm CPU = 1 MEMORY = 128 DISK = [ IMAGE="Ubuntu Karmic" ] NIC = [ NETWORK="Public" ]
The DISK Attribute will be translated by OpenNebula toDISK = [ SOURCE = "/srv/cloud/images/ubuntu.img", CLONE="yes", TARGET="sda1" ]
Users can override the repository values. Obviously, the use of the image repository is optional.
- The repository functionality will be exposed by the XML-RPC interface. A new CLI command
onestorageand OCA bindings will be developed.
Associated revisions
feature #200: More code for Image Pool
feature-#200: Polishing ImagePool classes
feature-#200: Finishing image pool
feature-#200: Added to SConstruct
feature #200: Source path generation fixed, and removed target attribute.
feature #200: Description and bus type columns removed for Image elements.
feature #200: Insert, replace and remove methods for Image update the DB immediately.
feature #200: Added Unit Tests for image pool
feature #200: Image pool table definition changed to be compatible with both MySQL and Sqlite.
feature #200: Specific tests for image pool
feature #200: Removing unnecesary line
feature #200: Images can now modify a DISK attribute vector to include correct BUS and TARGET.
feature #200: Fixed default type check.
feature #200: Image's get_disk_attribute now adds SOURCE attribute as well.
feature #200: ImagePool's contructor changed to load existing images from the DB.
feature #200: New erase method for Template class: removes and frees attributes with the given name.
feature #200: Fixed bad comment
feature #200: Preparing RM for Image methods
feature #200: Initial integration of ImagePool
feature #200: Added Image Info method to Request Manager
feature #200: Added ImageAllocate method to RM
feature #200: Added ImagePoolInfo method to RM
feature #200: Public attribute moved to main image sql table.
feature #200: Changed ImagePool Info method to be consistent with other pools.
feature #200: Making ImageInfo aware of the Public attribute
feature #200: Added Image Delete RM method
feature #200: Addde Image Update method
feature #200: PUBLIC attribute changed from TEXT to INTEGER.
feature #200: Fixed public attribute wrong type (from string to int)
feature #200: Update image in DB after modifying attribute
feature #200: Added OCA methods
feature #200: Added states and type to Image OCA
feature #200: Initial commit of "oneimage" command
feature #200: Fix troublesome deadlock
feature #200: Addded username to Image dump
feature #200: Finishing the CLI
feature #200: New states for Images and associated life-cycle functions
feature #200: Disable/Enable methods for the Image Class
feature #200: New enable/publish methods, changed ImagePool interface for modifying template attributes.
feature #200: Generate Disk attributes with the ImagePool metadata
feature #200: Adding enable, publish & remove attribute for images to RM
feature #200: Removed unused tag
feature #200: ImagePool allocate and disk_attribute methods.
feature #200: Some fixes for Image RM
feature #200: fix some tests
feature #200: Added enable, publish & remove attribute to Image OCA
feature #200: Added the IID to the DISK attribute
feature #200: Disks attribute generation includes image acquire.
feature #200: Integrates ImagePool and VirtualMachinePool. Now you can requests Images from VM templates!
feature #200: install Image files for OCA
feature #200: Also installs oneimage
feature #200: Adding new Image funcionality to the CLI
feature #200: spaces in oned.conf
feature #200: Release acquired images
feature #200: Useless breaks in oneimage
feature #200: Fixed some minor bugs
feature #200: Fixed the tests.
feature #200: Images are set DISABLED upon creation (and not INIT). DISABLED names for oneimage
feature #200: enable images to get disk attributes
feature #200: one_auth file to setup a user pool for the ImagePool tests
feature #200: Some minor fixes
feature #200: Added copy to repository feature to oneimage
feature #200: Added publish method to virtual network
feature #200: Fix bug in copy control of oneimage
feature #200: Adding VN publish/unpublish methods
feature #200: Adding missing RM file
feature #200: Image initialization code refactor
feature #200: Slight modification of configuration attributes for the pool
feature #200: Image update should not update the template
feature #200: Finising the Virtual Network publish functionality
feature #200: Erase PUBLIC attribute from image template.
feature #200: Remove selecting max oid from template SQL
feature #200: Adding missing unlocks for RM managed objects
feature #200: Removing unneeded callbacks from TemplateSQL
feature #200: Now VirtualMachine uses the same OID for VM and its templates
feature #200: fixed bugs in image hook
feature #200:Fix tests
feature #200: Homogenous insert/allocate methods
feature #200: Polishing the oneimage CLI
feature #200: Added support for empty datablocks
feature #200: Correcting wrong error hadling
feature #200: Prevents dead-lock and removes some blank lines
feature #200: Auth for VirtualNetworks
feature #200 Added ImageManager for Image management in OCA
feature #200: Minor modifications to ImageManager class
feature #200 Added ImageManager for Image management in OCA
Applied in wrong branch
Revert "feature #200 Added ImageManager for Image management in OCA"
This reverts commit c612987ada52530c13b1f70886cd55c0d1b53fa0.
feature #200 Changed OCCI XML Representation
feature #200 Fixed minor Errors in OCCI
feature #200 Show more information in OCCI resources
feature #200 EC2 using ImagePool
feature #200: Image now uses fileutils instead of ftools
feature #200: get rid of unneeded variables in config file
feature #200: removed uneeded print messages
feature #200: Better XML parsing
feature #200: Better XML parsing for ImageOCCI
feature #200: Examples for the OCCI service
feature #200: Removed unneeded rm component for cloud servers
feature #200: rm is no longer installed
feature #200: Get rid of Crack library for OCCI. OCCI now uses OpenNebula authorization mechanisms
feature #200: restored get_user for the EC2 Server
feature #200: Image Repository Integration for EC2 query
feature #200: Some work on the cloud servers
feature #200: Removed unneeded attribute variables
feature #200 Changes in EC2
feature #200 Delete upcase from XMLUtils and XMLElement and XMLPool for Pool
feature #200 Changes in OCCI
feature #200: XMLUtil class hierarchy
feature #200 Fixed error in PoolElement []
feature #200 Fixed uppercase paths in xml
feature #200: Fix uppercase XPATH variables
feature #200: Added default DISK_ID, simplified states
feature #200: Fix CLONE and SAVE attributes for the image pool
feature #200: XML-RPC method for saving images while a VM is executing.
feature #200: RM Class for saving disks.
Changed the buttons style in 'Role Affinity' (#200)
History
#1
Updated by Gyula Csom about 11 years ago
Hi!
In our environment we'd like to let users to upload their SSH keys, customization scripts, etc. generally speaking to upload any file they want to use in order to contextualize their VMs. My question are the following. Will the new image repository target end users, eg. exposed thru the OCCI interface too? Especially will the new functionality target the above use case or just cover images? Is their any plan in this regard?
Cheers,
Gyula
Ps.: As far as I see there's nothing that would prevent users from uploading any file thru OCCI by using the image upload method already built into ONE. It could be an image or anything else they want. So technically speaking it seems that we can provide the above functionality (with the appropiate conventions and ERB templates). However it would be useful to provide some metadata support, too, eg. to let users to describe the files they uploaded.
#2
Updated by Ruben S. Montero about 11 years ago
Gyula Csom wrote:
My question are the following. Will the new image repository target end users, eg. exposed thru the OCCI interface too?
Yes our plan is to expose this through OCCI/EC2
Especially will the new functionality target the above use case or just cover images?
Initially we will target VM images
Is their any plan in this regard?
As a follow up development we will address this!
Cheers
#3
Updated by Ruben S. Montero about 11 years ago
- Status changed from New to Assigned
- Assignee changed from Javi Fontan to Tino Vázquez
#4
Updated by Carlos Martín about 11 years ago
A quick comment on features that would be worth considering in next releases:
Right now, images contain the data and the necessary attributes to mount them as VM disks.
For OS type images, it would be nice to have also attributes for MEMORY, CPU, and BOOT sections of the VM template. This way, a user could decide to use an OS available in the repository with a simple template, like this one:
NAME = "My VM" OS_IMAGE = "Ubuntu desktop" DISK = "Accounts"
#5
Updated by Gyula Csom about 11 years ago
I agree:)
In our system (currently) we define similar metaadatas for (OS) images:
- PATH
- SIZE (optional)
- OS_TYPE, OS_VERSION
- ARCHITECTURE
- DESC
so a sample image "template" might look like this:
PATH=iscsi://storage.sample.com/iqn.2010-07.com.sample:1111/0 SIZE="20 G" OS_TYPE=Ubuntu OS_VERSION=9 ARCHITECTURE=x86 DESC="Ubuntu server customized for webservers"
Now the user can choose the image by the various metadatas available and can link it to the VM template...
Cheers,
Gyula
#6
Updated by Daniel Molina almost 11 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100