Page History

...

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 on 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
  • button for those
  )
  • two
• 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?

...