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
