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 <vbellur@xxxxxxxxxx> wrote: > >> On Tuesday 09 June 2015 04:42 PM, Ramana Raja wrote: >> ----- Vijay Bellur <vbellur@xxxxxxxxxx> 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 Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
