One of the sad things about working on filesystems is that it’s hard to demonstrate what makes your file system so special. So you wrote some files and then read them back? Big deal. Everyone does that. Performance graphs might impress one’s fellows, and demonstrating survival of a disk/server failure might even get a raised eyebrow from a non-specialist, but that’s about it. This matters not only for impressing others, but for getting that feeling of progress as you develop the code. This is the kind of work where you work on one piece and then another and then another, none of them seeming to do very much, until you bring them all together and then BAM! Suddenly you start getting visible results, usually not very good results to start with, but still something besides more source code sitting in your repository. That’s why writing management code, which can be just drudgery of a different sort if you do it all the time, can be so satisfying as a change of pace. Add a few lines, test, see visible results. Amazing.
Over the last few days, in the post-Summit lull, I’ve been working on the CloudFS management code. Most of it was written by Kaleb, but he was itching to tackle something more challenging, so I did some of the final integration with the rest of what’s there. It’s still very primitive by professional user-interface standards, but that’s kind of design. Many times while doing this, I stopped to ask myself whether I was working on presentation or plumbing. I really want to get all of the plumbing right but, whenever I realized I was working on presentation, I changed direction because some day we’ll need to get a real user-interface person in (any volunteers?) and anything I do in that area now will probably be replaced. The immediate goal is something that works, and that’s just barely pleasant enough that I as a developer won’t mind using it as I go about my other work. Yep, dog food again. All functionality is available via a command-line interface, as described in the manual, but I also have actual screen shots too (click images for full-size versions).
This is where you can see which nodes are part of your GlusterFS/CloudFS cluster (“pool” in Gluster terminology) and add new nodes as long as they have the software installed (and ssh access).
This is probably the most useful screen for most people. It lets you see what volumes you have defined, create new ones, start/stop them, and so on. Starting and stopping is done the CloudFS way, which includes rewriting the configuration files automatically, integrating with our own daemon- and port-management code, etc. instead of using Gluster’s mechanisms for that (which are inadequate for CloudFS’s needs and unlikely to improve in that direction). There’s also a client-side mount script that uses this different infrastructure to generate the client-side configuration and map to the proper ports, so that users don’t need to be aware of all that complexity.
Now we start getting into actual CloudFS-specific functionality. This is where you can list, add, and remove CloudFS tenants. Don’t be scared off by the appearance of a password in this screen. That’s just a temporary artifact of the crummy mechanisms GlusterFS already has for access control. By the time this gets release “into the wild” the password will be replaced by a certificate (generated using a client’s private key and signed by the provider) which is used for the low-level SSL transport. Also, everything in the web interface will be done using HTTPS with separate management-specific certificates on both the server and client sides. I’ll work out the interface for some of that as I develop the underlying functionality, but the main point is that the final version will be much more secure than what’s shown above.
Finally, the real key to CloudFS multi-tenancy. This is where you select which volumes a particular tenant can use; I plan to have a complementary screen to select which tenants can access a particular volume, but it doesn’t exist yet. This is more than superficial. When a CloudFS volume is started from the volume-management screen, or via the corresponding cfs_start_volume CLI, part of what happens is that the original GlusterFS “volfiles” are processed using the current list of allowed tenants to generate the CloudFS volfiles that will actually be used by the glusterfsd processes we start. Those processes then export tenant-specific volumes for clients to use based on the tenant identity and credentials provided to the mount script, and those volumes are configured to use tenant-specific mapping of user and group IDs. This is how we keep tenants strongly isolated from one another. The SSL transport module will also be added as part of this process, as will server-side helper translators to support the on-disk encryption (though the encryption itself and the keys it uses remain entirely on the client side).
That’s it for now. As I said, it’s still rather primitive, but at least it’s something I can show people. Some parts of it might even be useful for GlusterFS users who don’t even need CloudFS’s extra features. If you agree, feel free to grab the source code and hack away, or let me know in the comments here and we can talk about what needs to be done about splitting it from the rest of CloudFS.