Page History

...

• '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 (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?

...