Feature #683
RFC : Have a kernel/initrd/file repository
Status: | Closed | Start date: | 06/15/2011 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | - | |||
Target version: | Release 4.0 | |||
Resolution: | fixed | Pull request: |
Description
Hi.
It would be nice to manage kernels and initrd files within OpenNebula
Use case : I have PV Xen machines. I would like to manage several kernels, and maybe even have them listed in Sunstone.
I think the most generic way to do so would have to have a file repository. This should be distinct from the image repository, and used only for (rather) small files (kernels, certificates, configuration files, etc).
The way I see it, a file would have :
- an id
- a user-friendly name
- an owner/group/whatever is required for ownership
- meta-data key-value pairs
- one meta-data pair would be called "type", and could have values such as "context", "kernel", or "initrd"
- users could specify arbitrary pairs.
Tags would allow to mark a file as 'kernel' or 'initrd' or whatever the user wants.
Files would be uploaded through the XMLRPC API (so, small files only), and passed to an arbitrary driver with the following operations :
- CREATE
- DELETE
- LN
The usage scenario would go like this :
- I compile a new kernel and initrd
- I upload those to the File Store as vmlinuz-3.0-shiny and initrd-3.0-shiny
- I create a VM template looking like :
OS=[
INITRD=initrd-3.0-shiny,
KERNEL=vmlinuz-3.0-shiny,
KERNEL_CMD=ro,
ROOT=xvda1 ]
- The template builder realizes these are not paths (not starting with /)
- The files are copied (or linked) to /srv/cloud/X/files/
- The files are used in the deployment file
- When the VM is shut down, /srv/cloud/X/files/ is removed
Files uploaded that way could also serve in contextualization, without the security issue we discussed earlier. A file marked as "context" could be copied to the contextualization iso.
This could be extended even further. For instance, we could have a key-value pair called "host". Then, in the context part, have :
CONTEXT [ FILES = "$FILES[host=$HOSTNAME]" ]
Related issues
History
#1 Updated by Ruben S. Montero almost 10 years ago
- Tracker changed from Feature to Request
#2 Updated by Ruben S. Montero over 8 years ago
- Tracker changed from Request to Feature
- Target version set to Release 4.0
This will be implemented as part of #1617
#3 Updated by Ruben S. Montero over 8 years ago
- Status changed from New to Closed
- Resolution set to fixed
This has been implemented, mostly as described here using the Datastore abstraction.