...
Because the object storage data is often large and very network intensive, we do not want the data to actually flow through the CloudStack box as it would introduce a huge bottleneck. Because of this, there is no Java component of this implementation in CloudStack. Instead, the traffic is routed to Swift or CloudStack, based on the url structure, by a load balancer which sits in front of the two services. The technology used for load balancing (and ssl termination) is not important, but to illustrate the concept, I used HAproxy and Pound for these tasks.
...
- 'Object Store' added to the main services menu on the left
- When 'Object Store' is selected, the user is seamlessly authenticated and shown a UI for Swift
- User can List all containers and objects in their Swift account
- User can Add/Delete Swift Containers
- Supports cascade delete, so it will first delete all the objects in the container if there are any
- User can Add/Delete Swift Objects
- User can Add/Delete Folders in containers to group objects (unique to this implementation)
- Supports cascade delete of folders, so it will first delete all the objects in the folder if there are any
- User can create containers as Public or Private
- Public - Each object in the container can be accessed without needing authentication
- Private - Each object in the container requires the user to authenticate to access itthe object
- User can modify the Public/Private setting for existing containers
- A public URL is shown in the details for each object in a public container
- Supports sharing a Swift account with all users in a specific CS account (global setting)
- Supports giving each user in a CS account their own Swift account (global setting)
...
- When a user logs in, a change had to be made to add the 'api key' to the CS user object in the browser
- This Swift object storage service implementation is only available to users who have an API Key generated in CS
- It gracefully handles when a user does not have an api key generated and tells the user what to do in order for the functionality to work
- Another option would be to hide the Object Store service menu unless the user has an API key, but that did not feel like a constructive approachThere is a graceful degradation to explain to the user to to get the service to work if they try to use it without api keys
- The load balancer exposes the URL that is to be used by both CloudStack and Swift calls
- One reason for this is to make sure the Swift traffic does not go through the CS server which would create a bottleneck
- Another reason is to be able to make AJAX calls from the client to Swift without having issues with the Same Origin Policy
- All Swift calls are done using AJAX and the load balancer handles routing the calls to Swift
- UI This implementation is implemented entirely on the client side, without any Java backend in CloudStack
- Swift uses the HTTP PUT verb and , but browsers do not support the PUT verb, so the client sends the PUT requests as POST and the LB translates them to PUT
- This means that the current implementation does not support any of the Swift API calls that require POST (this has not been a limiting factor yet)
- More details on this can be found in the HAproxy config attached at the end of this document
- Line: reqirep ^POST\s+(.*)$ PUT\ \1
- This functionality requires the 'mauth' middleware to be installed on and configured in the Swift cluster
- The mauth configuration points to CS (the load balancer actually) and requires the 'admin' api keys (mauth requires
- mauth needs access to the 'listUsers' CS API call for all accounts
) - It is VERY strongly recommended to use CS on HTTPS (with SSL)
- Swift Usage Reporting is not included in this integration (see the note at the end of this file)
- TODO - Important - A global variable needs to be added to CS to enable/disable the Object Store functionality
- TODO - Medium - Clean up the couple places where text is not translatable
- TODO - Nice-to-have - Find a cleaner solution when someone tries to download a folder or container (
- currently downloading a container will result in an XML list of all of the objects in the container
- currently downloading a folder will just result in an empty file
- maybe I should just hide the download
of ) - TODO - Nice-to-have - Make the public URL for a public object clickable (it is just text right now)
- TODO - Nice-to-have - Reflect the full object path in the breadcrumb when an object is in detail view
- TODO - Nice-to-have - Remember what containers and folders were open and reopen them after a new container is added (enhancement)
- TODO - Nice-to-have - When a container or folder is clicked, expand/collapse it rather than forcing the arrow to be clicked (CS treeView enhancement)
- I do not like the current implementation in CS and I would like to change it
- Currently: If you click on a parent item, it will just show it in details, but it will not expand to show the children and it feels very un-natural
- I Want: When a parent item is clicked, it shows the details, but it ALSO expands/collapses the tree structure (so you don't have to click the tiny arrow as well)
- TODO - Medium - A user guide to explain the setup required to get Swift setup with mauth as well as setting the load balancer in front of CS and Swift
- What is the best way to make this doc available?
...