I agree Vijay, that is why we created Heketi, due to the urgency in Gluster and Manila integration for Liberty. I think the next steps are to determine which of the RFEs below can be satisfied by Heketi.
Luis > On Jun 15, 2015, at 3:26 AM, Vijay Bellur <[email protected]> wrote: > >> On Tuesday 09 June 2015 04:42 PM, Ramana Raja wrote: >> ----- Vijay Bellur <[email protected]> wrote: >>> >>> Would you be able to provide more light on the nature of features/APIs >>> planned to be exposed through Manila in Liberty? Having that information >>> can play an important part in prioritizing and arriving at a decision. >>> >>> Regards, >>> Vijay >> >> Sure! The preliminary list of APIs that a Manila share driver, which >> talks to the storage backend, must support to be included in Liberty, >> the upcoming Manila release in Sep/Oct 2015, would be available to >> the Manila community sometime later this week. But it can be >> inferred from the Manila mailing lists and the Manila community >> meetings that the driver APIs for actions such as >> - snapshotting a share, >> - creating a share from a snapshot, >> - providing read-only access level to a share, >> - resizing (extend or shrink) a share, >> besides the basic ones such as creating/deleting a share, >> allowing/denying access to a share would mostly likely be in the list >> of must-haves. >> >> There are two GlusterFS based share drivers in the current Manila >> release, "glusterfs", and "glusterfs_native" that support NFS and >> native protocol access of shares respectively. The "glusterfs driver" >> treats a top-level directory in a GlusterFS volume as a share (dir >> mapped share layout) and performs share actions at the directory level >> in the GlusterFS backend. And the "gluster_native driver" treats a >> GlusterFS volume as a share (vol mapped share layout) and performs >> share actions at the volume level. But for the Liberty release we'd >> make both the drivers be able to work with either one of the share >> layouts depending on a configurable. >> >> Our first target is to make both our drivers support the must-have >> APIs for Liberty. We figured that if the volume based layout is used >> by both the drivers, then with existing GlusterFS features it would >> be possible for the drivers to support the must-have APIs, but with >> one caveat - the drivers would have to continue using a work around >> that makes the cloud/storage admin tasks in OpenStack deployments >> cumbersome and has to be done away with in the upcoming release i.e., >> to create a share of specific size, pick a GlusterFS volume from among >> many already created in various Gluster clusters. The limitation can >> be overcome (as csaba mentioned earlier in this thread), >> "We need a volume creation operation that creates a volume just by >> passing the name and the prospective size of it." The RFE >> for create_share API, >> Bug 1226772 – [RFE] GlusterFS Smart volume management >> >> It's also possible for the drivers to have the minimum API set >> using the directory based share layout provided GlusterFS supports >> the following operations needed for >> - create_snapshot API, >> Bug 1226207 – [RFE] directory level snapshot create >> - create_share_from_snapshot API, >> Bug 1226210 – [RFE] directory level snapshot clone >> - allow/deny_access APIs in gluster_native driver, as the driver >> relies on GlusterFS's TLS support to provide secure access to the >> shares, >> Bug 1226220 – [RFE] directory level SSL/TLS auth >> - read-only access to shares, >> Bug 1226788 – [RFE] per-directory read-only accesss >> >> And for a clean Manila-GlusterFS integration we'd like to have >> high-level query features, >> Bug 1226225 – [RFE] volume size query support >> Bug 1226776 – [RFE] volume capability query >> >> Hope this helps the community to let us know the feature sets - >> smart volume management, directory level features, query features - >> GlusterFS can support by early August and those that it can >> support later, while we strive to increase GlusterFS's adoption in >> OpenStack (Manila) cloud deployments. >> > > > Given the current timelines, I am more inclined to go with the volume mapped > share layout (further referred to as volume layout) for both drivers as it > already seems to support the desired features for the Liberty cycle. > > I also feel that Manila drivers are doing a lot more orchestration for > supporting shares with gluster than they need to today. Going ahead, I am > thinking about a higher level service in gluster that exposes a ReSTful > interface for manila drivers to call out to and have the intelligence > embedded there. > > For instance, the workflow for a share create request in Manila could look > like this in the new model: > > > Users ----> create_share (size...) (manila with gluster driver) > | > | > create_gluster_share (size...) > | > | > -----> gluster-storage-as-a-service-daemon > | > | > -------> Transaction over gluster CLI etc. > > The response would flow in the reverse direction. I feel that there are more > consumers of gluster who can benefit from this and have some early thoughts > on the APIs that should be part of the interface for > gluster-storage-as-a-service. > > All of the requirements that Manila needs like SmartVolumeManagement, choice > of volume or directory layout per tenant, querying abilities that you allude > to could be built in this new service. > > The volume layout today cannot possibly scale to thousands of tenants but > with the scalability improvements slotted for 4.0 and the abstraction that we > plan to provide through the new daemon it should be easier for Manila & other > services to integrate with gluster. If there are other RFEs/bugs that would > need to be addressed for the volume layout sooner, please update this thread > and let us work together to have them addressed in the Liberty release cycle. > > Regards, > Vijay > > _______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
