This post is more than 5 years old
5 Practitioner
•
274.2K Posts
0
2892
What's the difference between OpenStack Swift and existing API calls for Isilon?
I've been writing some PowerShell scripts the past month or so which uses existing OneFS REST API calls to manipulate shares, exports, quotas, snapshots, etc. This is something I can do without a 'Swift' license, and apparently works in code versions as early as 7.0.2.x of OneFS.
I'm trying to understand how OpenStack Swift is different than what OneFS already provides in regard to making API calls to GET/PUT/POST etc. Are there added benefits to using Swift? It appears that you need at least OneFS 7.2+ to take advantage, but I'm not sure to what advantage I'd be gaining.
I started to read a little more into Swift, but I guess I'm just trying to find the key value it adds to OneFS. Does anyone have experience, or studied up so they can shine the light on this for me?
AdamFox
254 Posts
0
February 1st, 2016 09:00
They are quite different. First I will make a distinction between PAPI and RAN.
PAPI is the Platform API that allows you to administer the cluster. It is not about accessing files.
RAN is Restful Access to the Namespace and is about accessing files. I assume this is what you are using.
The difference between RAN and Swift is that RAN sees the namespace as a filesystem. This means you have calls to do just about anything you could do from a protocol. You can view and alter Windows ACLs, for example. You are getting a Restful view of the cluster.
Swift is a true object store standard. That means that you don't think about things like file permissions. You access objects through an account and the account is the controlling factor. OneFS still enforces file permissions because we have to, but the Swift Protocol itself doesn't see it that way. There are some other significant changes coming in the next major release of OneFS that I can discuss once I see it posted but I will say that things like accounts and user access are quite different as well as location of accounts and containers.
The trick is to use the protocol that makes sense to your workflow. Swift is nice in that it's an open standard but if you still need to interact with the data as if it's in a filesystem, (e.g. you want to view and manipulate permissions), Swift isn't for you.
Bottom line, one is simply a RESTful interface to a filesystem, the other is an true object store.
Hope this helps.
sluetze
300 Posts
1
February 1st, 2016 00:00
Hi,
Swift gives you the ability to use the Isilon as object-storage for application which utilize objects.
Not more. Note less.
It does not help you to "manage" the Cluster in other ways for file-based protocols.
rgds,
---sluetze
carlilek
205 Posts
0
February 1st, 2016 09:00
Ah, if I can just set it to /ifs, that works for me.
AdamFox
254 Posts
0
February 1st, 2016 09:00
It's a case of you can't please everyone. We tried forcing users to home directories and folks who wanted to use Swift customers complained (apparently loudly).
You can still open up the Swift directories to other protocols. It's just that the path for Swift is set. Swift isn't AZ aware, so it's off of the root /ifs. That may get tweaked if/when AZ support comes to Swift.
AdamFox
254 Posts
0
February 1st, 2016 09:00
Ok. I just noticed that 8.0 is posted so I can be a bit more specific.
In 8.0 we made some changes to Swift to make it more like a standard Swift server. We now require a specific Swift account for users to access the cluster via Swift. That account can be associated with a regular account for file permission purposes, but just turning on Swift no longer means that just anyone can access it via Swift.
We also changed where Swift account live. There is a specific path (something like /ifs/lwSwift or something like that, I'd have to look it up). Prior to 8.0, we just used user home directories which had to be defined.
carlilek
205 Posts
0
February 1st, 2016 09:00
Hmm. I'm not thrilled with forcing Swift access to a specific path (which sounds like it needs to be dedicated to it.) Not exactly all protocols can access anything...
AdamFox
254 Posts
0
February 1st, 2016 10:00
I didn’t say that. It’s a specific path off of /ifs.
carlilek
205 Posts
0
February 1st, 2016 11:00
Not particularly data lake-y then. More like data pond that's next to other data ponds.