Use Case: Management Dashboard

• Name: Manage cloud resources from a centralized dashboard
• Contact: Shlomo Swidler
• Description: An end user wishes to view and control all of his cloud-based resources in a lightweight (perhaps AJAX-based) console, perhaps the same web front-end referred to in this use case: AJAX web front-end directly calling API
• Functional Requirements
  • Completeness: Every resource provided by the cloud is discoverable by the API, and every action that can be performed on all these resources is also available via the API, together with actuators to actually perform those actions, and all the attributes of the resources are available via the API.
  • Responsiveness: Calls must return swiftly. In particular, we should provide a simple and quick call to poll the _list_ of servers, drives, etc. that exist without listing all of their properties, since this is computationally much cheaper for the cloud to return, and will need to be regularly polled to catch any servers, etc. that are created outside of the interface. (text copied from AJAX web front-end directly calling API)
  • Categorizability: (there's gotta be a better word...) The client must be able to identify what type each resource is in order to display like-typed resources together and in order to provide separate UI views that might be specialized for certain resource types. For example, the client must be able to differentiate between a compute resource that does not represent an actual CPU (perhaps this is a compute template) and between a compute resource that actually represents a running CPU. The interface for actually-running CPUs might display the current IP address of the instance and allow you to SSH into the instance, while a different tab in the interface might display all the compute templates and allow you to instantiate instances from them.
  • Taggability: Every resource discoverable by the API must be able to be tagged by the user. This supports the oft-occurring situation where resources, though they are identified by the implementation-specific identifier, are easily identified using terminology defined by the user for his specific context. For example, one might tag resource "/compute/instanceABCDEFG" with the label "database server", and the resource "/storage/disk12345678" with the label "superSecretCorporateData".
  • Searchability: The ability to request lists of resources must allow an optional filter that can specify a category or tag upon which to filter the results. This allows one to further limit their view to, for example, resources tagged "productionEnvironment", or resources of the category "storage".
• Non-functional Requirements
  • Usability: This should be a user interface with context-menus and context-aware links that allow the user to easily see what actions can be performed for each resource.