[Thincrust-devel] USER STORIES --type

[Bryan Kearney]

David Huff wrote:
> Bryan Kearney wrote:
>> Joey Boggs wrote:
>>> Only allows 1 disk in a kickstart currently, anymore will fail. 
>>> Working on the virt-convert scenarios next.
>>
>> I testted it and got the error below. Couple of comments
>>
>> 1) If I specify the --appliancetype then is the format, vmem, and vcpu 
>> items ignored? Huff, based on our chats yesterday should this be --type
>> (to prep for package, ovf, vmware etc)
>>
> 
> So I started to summarize our conversation from yesterday, where we 
> decided that there should be a --type flag that sets/overrides all other 
> options for that type.  Below are some of my thoughts form the 
> discussion.....
> 
> Valid types would be, KVM, XEN, VMARE, EC2.
So, type is hypervisor? Is so, then packging should be libvirt? That is 
kinda wierd since libvirt can (in some cases) abstract out hypervisor.
> Overwritten options are, DISK FORMAT, META-DATA FORMAT, VMEM, VCPU, 
> PACKAGE TYPE
> Package formats can be: TAR, ZIP, OVF, other
> 
> When I started thinking about implementation I started confusing myself, 
>  the existing tools in this arena are:
> VIRT-CONVERT - converts vmware to libvirt calls qemu-img
> VIRT-PACK - converts libvirt to vmware[1]

In the latest release notes, it was mentioned that this would go into 
virt-convert.

> QEMU-IMG - converts disk formats
> EC2-CONVERTER - converts libvirt to ec2 appliance[1]
> *as far as I know, nothing exist to package appliance. This could be 
> either stuck in appliance-tools or virt-convert
> 
> 
> I thought it might be helpful to start simple with user stories...
> User Stories:
> 
> 1. Build a KVM appliance with 512M and 1VPUS, using a qcow2 formatted 
> disk image, packed with libvirt meta-data in a zip file.
> 
> 2. Build a VMWARE appliance with 512M and 1VPUS in a OVF bundle
> 
> 3. Build a XEN appliance that will run on RHEL5, with 512M and 1VPUS, 
> with a RAW disk image, libvirt meta-data packaged in a tar.gz bundle [2]
> 
> 4. Bild a EC2 appliance and deploy to cloud. (lagre small type???)
> 
> * In all 4 user stories, the appliance should be described with the same 
> kickstart file, and build using the same appliance-creator command with 
> the exception of --type

This is the goal. The question is can we assume/determine enough 
information to convert to all the target hypervisors (including paravirt 
ones).  I think the user may want the the ueber-use case which is build 
them all, and let the end customer pick the hypervisor of their choice.

So.. i think the question we may want to take to the virt team is how 
much do they want to do in virt-convirt. Should that layer modify the 
disk image internals (like the ec2 convereter does) or does that tool 
stick to metadata and we put a layer on top.

> 
> 
> [1] not sure if or how kernel modules or drives are handled, and my 
> understating is they are needed.
> [2] not sure if virt convert can handle this and/or what changes need to 
> be make to meta-data

I think we will want to work to add the ability to take in a signed 
packaged into virt-image.