Hi Jay! I have comments below: ----- Original Message ----- From: "Jay Vyas" <jayunit...@gmail.com> To: "Joseph Fernandes" <josfe...@redhat.com> Cc: "John Spray" <jsp...@redhat.com>, "Gluster Devel" <gluster-devel@gluster.org> Sent: Thursday, June 18, 2015 9:33:12 AM Subject: Re: [Gluster-devel] Introducing Heketi: Storage Management Framework with Plugins for GlusterFS volumes
Thanks for annoying letting us know about this so early on; I don't fully understand the plugin functionality .... So I have some general questions. But am very interested in this. 0) I notice it's largely written in go,compared to the gluster ecosystem which is mostly Python and C. Any reason why? I like go but just curious if there are some technical requirements driving this and if Go might become a more integral part of the gluster core in the future. [LP] Why Go? http://www.g33knotes.org/2014/09/why-i-think-go-provides-excellent.html ;-) .. Maybe GlusterFS will start using Go. But joking aside, it provides an excellent platform for RESTful interfaces and unmatched deployment. 1) is heketi something that would allow things like raid and lvm and so on to be moved from core dependencies into extensions, thus modularizing using glusters core? [LP] Maybe. I'm not sure if heketi should be an orchestrator of storage, but I guess the plugin can do whatever it needs to do. 2) Will heketi actually be co-evolving / working hand in hand with fluster so that some of the storage administration stuff in glusters code base is moved into a broader framework? [LP] I hope so. The goal is for Heketi to provide the framework to allow plugins for storage systems (GlusterFS being one) to accept a set of standard REST commands and expose any others it needs - Luis > On Jun 18, 2015, at 9:07 AM, Joseph Fernandes <josfe...@redhat.com> wrote: > > Agreed we need not be depended ONE technology for the above. > But LVM is a strong contender as a single stable underlying technology that > provides the following. > We can make it plugin based :) . So that ppl who have LVM and are happy with > it can use it. > And we still can have other technology plugins developed in parallel, but let > have Single API standard defined for all. > > ~Joe > > ----- Original Message ----- > From: "Jeff Darcy" <jda...@redhat.com> > To: "Joseph Fernandes" <josfe...@redhat.com> > Cc: "Luis Pabon" <lpa...@redhat.com>, "Gluster Devel" > <gluster-devel@gluster.org>, "John Spray" <jsp...@redhat.com> > Sent: Thursday, June 18, 2015 5:15:37 PM > Subject: Re: Introducing Heketi: Storage Management Framework with Plugins > for GlusterFS volumes > >> LVM or Volume Manager Dependencies: >> 1) SNAPSHOTS: Gluster snapshots are LVM based > > The current implementation is LVM-centric, which is one reason uptake has > been so low. The intent was always to make it more generic, so that other > mechanisms could be used as well. > > > >> 2) PROVISIONING and ENFORCEMENT: >> As of today Gluster does not have any control on the size of the brick. It >> will consume the brick (xfs)mount point given >> to it without checking on how much it needs to consume. LVM (or any other >> volume manager) will be required to do space provisioning per brick and >> enforce >> limits on size of bricks. > > Some file systems have quota, or we can enforce our own. > >> 3) STORAGE SEGREGATION: >> LVM pools can be used to have storage segregation i.e having primary storage >> pools and secondary(for Gluster replica) pools, >> So that we can crave out proper space from the physical disks attached to >> each node. >> At a high level (i.e Heketi's User) disk space can be viewed as storage >> pools,(i.e by aggreating disk space per pool per node using glusterd) >> To start with we can have Primary pool and secondary pool(for Gluster >> replica) , where each file serving node in the cluster participates in >> these pools via the local LVM pools. > > This functionality in no way depends on LVM. In many cases, mere > subdirectories are sufficient. > >> 4) DATA PROTECTION: >> Further data protection using LVM RAID. Pools can be marked to have RAID >> support on them, courtesy of LVM RAID. >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/raid_volumes.html > > Given that we already have replication, erasure coding, etc. many users would > prefer not to reduce storage utilization even further with RAID. Others > would prefer to get the same functionality without LVM, e.g. with ZFS. That's > why RAID has always been - and should remain - optional. > > It's fine that we *can* use LVM features when and where they're available. > Building in *dependencies* on it has been a mistake every time, and repeating > a mistake doesn't make it anything else. > > JOE: > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
