[Gluster-devel] The Manila RFEs and why so

[Ramana Raja]

----- Vijay Bellur <vbellur at redhat.com> 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.

Thanks,

Ramana