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". >> >> 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. > > My feeling is that the external storage is for allowing admins to add > support for their own site-specific SANs/devices, but not for > something that we want to provide full support from Ganeti. I should dig into Ganeti for these stuffs. > > I think we should focus on qemu+gluster and just fallback to the other > method (if feasible without huge extra work). > We should also focus on providing gluster through Ganeti nodes (aka. > self-configuring of gluster via ganeti node add). I think so, too. Providing gluster through Ganeti nodes is well for me. > > 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. -- Thanks Harry Wei
