On Fri, Jul 12, 2013 at 10:45 PM, Guido Trotter <[email protected]>wrote:
> On Fri, Jul 12, 2013 at 11:10 PM, Lance Albertson <[email protected]> > wrote: > <snip> > So to me this means we need a new device type in bdev.py which could open > > the possibility of finally adding support for other image formats that > > qemu-img support (such as qcow2). But for this project we can just stick > to > > raw files. > > > > I don't understand if raw files are supported or not, and qemu-img is > a strict dependency. Anyway, either way we need a new class called > GlusterBlockDevice that is able to create/delete etc devices on > gluster. *if* this wants to (perhaps optionally) depend on a common > QemuImgDevice class, this is OK too. Then in the future perhaps > file/sharedfile could add Qemu Img support. > Raw files as its implemented now could be supported for the shared file support with glusterfs. The requirement for qemu-img is only for the libgfapi feature of GlusterFS+KVM since you would be making an API call using that binary to create the disk images. I agree that it should be a GlusterBlockDevice that depends on either FileStorage (sharedfile or file) or QemuImgDevice (libgfapi). > So my question for Ganeti devs is, should Harry make a new device type in > > bdev.py that specifically supports qemu-img (say QemuImgDevice)? It > doesn't > > have to only work for this GlusterFS feature but could potentially be > used > > for file and sharedfile as well. > > > > This would definitely be a good design (GlusterBlockDevice using > QemuImgDevice), but of course there's no need to change > file/sharedfile to support it right away. This can be done later > either by harry (after the summer of code) or by someone else. > I agree, we should not change how you do raw file storage for file/sharedfile with this project (only if he has time). However it would be good to possibly add that feature later which should be somewhat trivial. We could give people an option of either using the current method or qemu-img. > > I think initially we were looking at the rbd patch as an example however > > that doesn't exactly align 1:1 since we aren't directly accessing a block > > device. We're doing all of the operations via qemu-img or qemu (kvm) > > directly. > > > > Didn't we say there would also be (optional) direct access? Or was > that deemed not needed/too complex? > Anyway it's OK to behave similarly to rbd, but ignoring the direct > access part (or make them optional), as this is the plan for rbd > itself as well. > I'm not sure what you mean by direct access for gluster. The closest we'll get to that is via qemu-img as it uses libgfapi directly. But I agree with your assessment. Thanks! -- Lance Albertson Director Oregon State University | Open Source Lab
