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 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.

References

• mauth - An extensible middleware for OpenStack Swift which enables Swift to authenticate CloudStack users.  (Developed by Will Stevens @ CloudOps)

...

• 'Object Store' added to the main services menu on the left
• 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
• 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
• 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 it
• 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
• The load balancer exposes the URL that is used by both CloudStack and Swift calls
• All Swift calls are done using AJAX and the load balancer handles routing the calls to Swift
• 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
• TODO - A global variable needs to be added to CS to enable/disable the Object Store functionality
• TODO - Clean up the couple places where text is not translatable
• TODO - Find a cleaner solution when someone tries to download a folder or container (maybe I should just hide download of those)
• TODO - Make the public URL for a public object clickable (just text right now)
• TODO - Reflect the full object path in the breadcrumb when an object is in detail view
• TODO - Remember what containers and folders were open and reopen them after a new container is added (enhancement)
• TODO - When a container or folder is clicked, expand/collapse it rather than forcing the arrow to be clicked (CS treeView enhancement)
• 
  
• 
  
• put a summary or a brief description of the feature in question 
• list what is deliberately not supported or what the feature will not offer - to clear any prospective ambiguities
• list all open items or unresolved issues the developer is unable to decide about without further discussion
• quality risks (test guidelines)
  • functional
  • non functional: performance, scalability, stability, overload scenarios, etc
  • corner cases and boundary conditions
  • negative usage scenarios
• specify supportability characteristics:
  • what new logging (or at least the important one) is introduced
  • how to debug and troubleshoot
  • what are the audit events 
  • list JMX interfaces
  • graceful failure and recovery scenarios
  • possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
  • if feature depends other run-time environment related requirements, provide sanity check list for support people to run
• explain configuration characteristics:
  • configuration parameters or files introduced/changed
  • branding parameters or files introduced/changed
  • highlight parameters for performance tweaking
  • highlight how installation/upgrade scenarios change
• deployment requirements (fresh install vs. upgrade) if any
• system requirements: memory, CPU, desk space, etc
• interoperability and compatibility requirements:
  • OS
  • xenserver, hypervisors
  • storage, networks, other
• list localization and internationalization specifications 
• explain the impact and possible upgrade/migration solution introduced by the feature 
• explain performance & scalability implications when feature is used from small scale to large scale
• explain security specifications
  • list your evaluation of possible security attacks against the feature and the answers in your design* *
• explain marketing specifications
• explain levels or types of users communities of this feature (e.g. admin, user, etc)

...