[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Gluster w/ OpenShift?

On 01/29/2014 04:30 PM, Andrew Lau wrote:

The other day, I met some nice guys at a devops meetup and we ended up
talking about openshift and how I've been using it compared to the
traditional methods they're still using. Pro's and cons etc.

A question came up which prompted the thought, is it possible (or on any
roadmaps) to integrate glusterfs into openshift (ie. the node
application storage). Possibly like a centralized storage environment vs
the current know nothing infrastructure. Scaled web applications could
share the same storage backend allowing the support of user file uploads
on scaled applications rather than having to offload to something like
S3. I'm thinking more along the lines of then having the ability to do
easy migrations and fail over of gears.

This has been an ongoing point of research on my part internally. GlusterFS has some issues that, right now, make it not ideal for use with OpenShift, specifically there's still issues with SELinux contexts (this seems to be mostly a FUSE issue and working on getting that resolved upstream) and some potential performance issues that have been reported during my testing. There's some other, internal to OpenShift, issues with uid/gid's not being guaranteed unique across districts for example that would also limit some of the usefulness of a centralized storage environment.

The question has come up a couple of times, and sadly right now we don't have an ETA on when or if it would be added. It's definitely something we are keeping an eye on, though as there's a lot of potential for something like that to be added, including the advantages you've mentioned, but definitely not limited to that.

There's some other work that might be closer on the horizon for doing file synchronization across gears, which obviously doesn't have the same advantages as a shared file system, but at least has some of the same properties and fills in some of the same use cases (though obviously not as efficiently).

- John 'Warthog9' Hawley

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]