Please share with the community what you think needs improvement with SwiftStack.
What are its weaknesses? What would you like to see changed in a future version?
The file access needs improvement. The NFS was rolled out as a single service. It needs to be fully integrated into the proxy in a highly available fashion, like the regular proxy access is. I know it's on the roadmap. With some of the hierarchy, old management storage policies, I would like to be able to move data between different types of storage policies. One of the things that has come up before was being able to do distributed erasure coding. Right now, erasure coding is only supported locally redundant. Products, like Scality, support the ability using multiple rings to do erasure coding that's globally redundant.
At the moment we are using Erasure coding in an 8+4 setting. What would be nice is if, for some standard configurations like 15+4 and 8+4, there were more versatility so we could, for example, select 8+6, or the like.
I would like to see better client integrations, support for a broader client library. SwiftStack could be a little bit more involved in the client side: Python, Java, C, etc. We don't have a lot of issues, but if we do, we don't really get any support from them at all. It's not really in their business model, but it would be easier to integrate if they supported the clients a little bit better.
* The biggest room for improvement is the maturity of the proxyFS solution. That piece of code is relatively new, so most of our issues have been around the proxyFS. * Having the full feature set and the management APIs available, there is a lot of room for improvement there. * The code upgrade process at scale, managing code upgrades at large scale.
On the controller features, there needs to be a bit more clean up of the user interface. There are a lot of options available on the GUI which might be better organized or compartmentalized. There are times when you are going through the user interface and you have to look around for where the setting may be. A little bit more attention to the organization of the user interface would be helpful. They should provide a more concise hardware calculator when you're putting your capacity together.
When I started, SwiftStack was just a deployment model for OpenStack Swift. It did what it needed to do. There may have been some room for refinement procedurally in how to do certain management tasks. Over the years with ProxyFS, I don't know where the improvement would lie - whether it lies with SwiftStack or other vendors - but, in general, we need a model where more third-party companies support REST APIs, open REST APIs into object stores such as OpenStack Swift. I really don't see any great strides being taken to do so. There are a few, but a lot of them do the big players, like Amazon S3, and not the open-source players. The other thing that I've been looking for, for years as an end user and customer, for any object store, including SwiftStack, is some type of automated method for data archiving. Something where you would have a metadata tagging policy engine and a data mover all built into a single system that would automatically be able to take your data off your primary and put it into an object store in a non-proprietary way - which is key. A lot of them say they do it, but they do it with their own proprietary wrappers and then, if you don't have their system sitting in front of it, you can't access your data anymore. I think SwiftStack, with its value-add, that's where they're going. If they do that, they have a storage system that would kill all the others.