Single tenant GlusterFS Ganesha driver for Manila

single tenant Ganesha driver.md

#Single tenant GlusterFS Ganesha driver for Manila

The initial prototype of the Ganesha driver will be tailored to work for the GlusterFS backend, and in the next iteration will be made modular. The following operations will be supported initially:

• create
• delete
• access-allow
• access-deny

As a part of the initial set up, Manila will check whether the GlusterFS client and Ganesha server programs are installed in the host machine, and will fuse (mount) a GlusterFS volume on the host machine.

• create will create a subdirectory within the GlusterFS volume. will add a export block with an unique id to the Ganesha config file as follows, and start the Ganesha server process if not already started.

example 1

# Following is the content of a Gluster FSAL specific config file, say 
# export_gluster.conf which will be included by the primary Ganesha config file
# as in here http://pastebin.com/Ex4WSkHu
EXPORT{
Export_Id = 89;
Path="/glustervol00/share00";
FSAL {
name = GLUSTER;
hostname="172.16.53.47";
volume="glustervol00";
volpath="/share00";
}
Squash = No_root_squash;
Pseudo="/glustervol00/share00";
NFS_Protocols = "3,4" ;
Transport_Protocols = "UDP,TCP" ;
SecType = "sys";
Tag = "glustervol00";
}

• delete a sub directory within the Gluster volume will be deleted and also the export block of the subdirectory will be removed from the config file.

• access-allow A export entry will be added to the Ganesha configuration file to allow access of a share to an ip. The 'client' sub-block within the appropriate export block (identified by the export-id) will be added or edited. For e.g., let's say an user wants to allow access for a share to the ip 172.24.4.2, Manila will add the ip to the 'clients' key in the file as follows,

example 2

# export_gluster.conf file
EXPORT{
Export_Id = 89;
Path="/testvol00/dir1";
FSAL {
name = GLUSTER;
hostname="172.16.53.47";
volume="testvol00";
volpath="/dir1";
}
Squash = No_root_squash;
Pseudo="/testvol00/dir1";
NFS_Protocols = "3,4" ;
Transport_Protocols = "UDP,TCP" ;
SecType = "sys";
Tag = "testvol00";
client {
    clients= "172.16.53.43,172.24.4.2";
    Access_type = RW;
    Squash = No_root_squash;
    Transport_Protocols="TCP,UDP";
    NFS_Protocols = "3,4";
    anonymous_uid = -2;
    anonymous_gid = -2;
  }
}

• access-deny a export block will be edited in the config file. And the ip that will be denied access will be removed if present in the 'clients' key of the correct export block. And if the access-deny operation results in the value of 'clients' key being empty, the entire 'client' sub-block will be removed (the value of the 'clients' key cannot be empty).

Notes:

1. Ganesha can now dynamically manage exports. So the Ganesha server needn't be restarted after changing the config file for the changes to take effect. But I've not checked this feature yet.

2. Also we need to figure out how we could generate an unique export id and store it. It'd be nice if we could store the id in the manila db, as one of the fields in the manila share db object.

Written with StackEdit.