On Thu, May 2, 2013 at 8:04 AM, harryxiyou <[email protected]> wrote: > On Thu, May 2, 2013 at 2:01 AM, Guido Trotter <[email protected]> wrote: >> On Wed, May 1, 2013 at 7:37 PM, Lance Albertson <[email protected]> wrote: > > Hi Lance and Guido, > >>>> >>>> I don't see in the proposal the external storage interface mentioned, and >>>> indeed I am not sure we should use that to provide gluster support. Why not >>>> going for a "gluster" type inside Ganeti? This would also be the only way >>>> to >>>> make sure the qemu gluster inteface can be used easily. >>>> > > Yeah, actually, i think we should provide "gluster" type as an external > storage > back-end driver. Because i think it is just a kind of backend storage driver. > If > we provide for "gluster" inside, i am not sure the benefits. However, if it is > supported as one of external storage, the realization would be simple and > clear. Maybe i should study more with inside "gluster". >
The benefit with inside gluster is that it would not be opaque, but fully supported and integrated. I personally am in favor of that implementation, rather than an external one. Right now we provide the external interface, but no module for it. Putting one means we would need to add infrastructure for testing/qaing it and such, while having it internal we can leverage the normal infrastructure. Having it internal we can also provide a monitoring agent for it (see the monitoring agent design) and more visibility into what's going on. >>> I haven't used the external storage provider much myself but from reading >>> the design doc it seems to fit within the typical use case for that >>> provider. Why do you feel it doesn't fit well with it and that it requires >>> its own type? Perhaps I need to take a closer look at how the qemu gluster >>> interface actually works. Should we focus on getting the qemu gluster >>> interface working for Ganeti, the more typical way you use gluster with it >>> mounted on the Ganeti node, or try and focus on both? I think the qemu >>> gluster interface is the most ideal personally. > > I don't think qemu gluster would work for Ganeti because it can only support > for QEMU. We have other VM types. > Not a problem at all. It can be supported initially just for kvm, and we can provide the Xen support via the node, or later. I wouldn't focus on a suboptimal support just so it can be used by all machine types, when the only sensible production use case is the optimal one, which we wouldn't provide. >> The reason I felt that to use the qemu-gluster you need gluster as a >> primary type is that ext types are opaqua to Ganeti. As such they can >> only export "one block device" which qemu then uses. If we want to >> provide a hypervisor-specific way (like we do for gluster and ceph) we >> need for the hypervisor to be able to behave differently depending on >> the storage type, which we can't do with ext, since the backend is >> opaque then. :) >> > > I am not sure about what the opaque stuffs are. However, i cannot > understand why you want the backend not to be opaque. Perhaps i > need to take a closer study for Ganeti. > Well, if it is then for example how can qemu configure it via the userspace, rather than via the filesystem of the node? And we want it via the library, as lance said. :) Thanks, Guido
