Page History

...

• 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
  • There 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 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 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 is implemented entirely on the client side without any Java backend in CloudStack
• Swift uses the HTTP PUT verb and browsers do not support the PUT verb, so the client sends the requests as POST and the LB translates to PUT
  • This means that the current implementation does not support any of the Swift API calls that require POST
  • More details on this can be found in the HAproxy config attached at the end of this document
• This functionality requires the 'mauth' middleware to be installed on Swift
• The mauth configuration points to CS (the load balancer actually) and requires the 'admin' keys (mauth requires 'listUsers' API call for all accounts)
• It is VERY 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 (maybe I should just hide download of those)
• TODO - Nice-to-have - Make the public URL for a public object clickable (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)
• 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?

...

Note: If you have followed this implementation at all (from previous conferences), you may have heard of 'cs_auth' being used as the Swift auth middleware.  'cs_auth' was the first Swift auth middleware I wrote to authenticate CS users in Swift and was the predecessor of 'mauth'.  'mauth' will continue to be supported, but 'cs_auth' will not and should not be used for future projects.

Note: Regarding Swift Usage Reporting

The Swift implementation is made up of two parts, the auth middleware in Swift and the AJAX CloudStack UI in the users browser.  Since we are not integrating with the Java backend of CS at all, I have not implemented any Swift usage reporting in CS.  

However, I have developed a middleware for Swift called 'swift_usage' (git repo) that exposes the Swift usage for accounts as a REST API.  This was developed to be used with my auth middlewares, so that has been tested.  I have not touched this project in quite a while and it was only used by a small group of us, so I need to do a once over on the project to make it 'open source' ready.  I need to do a bit of a code cleanup and provide much better documentation, but the core is a working product already.  We will be using this project internally, so expect some updates soon.