Live notes may be taken for this topic at: http://etherpad.openstack.org/Requirements
Requirements solicitation for this Summit will focus on those areas of immediate interest for imminent development. In particular, the API and Image Caching, as these somewhat define the bounds of our system (customer interface and storage interface).
Note that these requirements are merely suggested at this point, and are meant as a centerpiece for discussion. Your involvement, edits, additions, and corrections are welcome and needed.
- The system shall support the capability to run multiple APIs.
- a) The system shall support the capability for each API to run in it's own URL namespace. (e.g., Rackspace vs. EC2)
- The system shall support fully asynchronous API design.
- a) The system shall support the option for synchronous APIs (e.g., IP Address)
- The system shall be secure
- a) if components fail, they shall fail closed
- b) a compromised component shall not lead to cascading compromising of entire system
- The system shall be transparent
- a) failure of components/operations shall be recorded for both cloud operators and users
- b) health of individual components shall be accessible for operations
API candidate functions
- The system shall support the capability to ...
- a) ... retrieve a list of servers.
- b) ... create a server.
- c) ... get details of a server.
- d) ... update the name of a server.
- e) ... update the administrative password of a server.
- f) ... delete a server.
- g) ... retrieve a list of addresses.
- h) ... retrieve a list of public addresses.
- i) ... retrieve a list of private addresses.
- j) ... share an IP address.
- k) ... unshare an IP address.
- l) ... reboot a server.
- m) ... rebuild a server.
- n) ... resize a server.
- ... confirm a resized server.
- ... revert a resized server.
- ... retrieve a list of available configurations (flavors).
- a) ... retrieve details of a selected configuration.
- b) ... retrieve a list of available images.
- c) ... create an image from an existing server.
- d) ... retrieve details of an image.
- e) ... delete a stored image.
- f) ... enable/disable scheduled back-ups of a server.
- indicate schedule for back-ups of a server.
- indicate retention policy for scheduled back-ups of a server.
- ... retrieve a list of shared IP groups.
- a) ... create shared IP groups.
- b) ... retrieve details on a shared IP group.
- c) ... delete a shared IP group.
- use webhooks (http callbacks) to send information on state change?
Projects/Groups & Users
- Access to resources should facility existing social structures (groups, roles)
- User can belong to many projects
- Users have roles
- API calls can be restricted to only users with proper roles
- Quotas on resource usage at project level (system wide default for all projects, with override)
- Audit logs of who did what to cloud resources
- User provided naming and descriptions facilitate groups
Running a cloud: Security / Management
- APIs / web interface for IT Security group (to deal with compromised guests)
- APIs for user / projects / roles / ...
- Basic reporting of statistics of utilization
- Tools to check cloud health (scheduled and on demand for specific hosts)
- The system shall provide the capability to cache images.
- a) The system shall provide the option not to cache images.
- b) The system shall provide the capability to configure expiration policy for an image (e.g., base images)
- The system shall provide the capability to interface with multiple image stores.
- a) The image store interface shall provide support for multiple sources/back-ends.
- b) The image store interface shall provide support for RS-CF, http, nfs.
- c) The image store interface shall be modular.
- The system shall provide support for OVF.
- a) Question: should we be supporting multiple VMs in a single OVF manifest?
- b) Question: what (other) portions of OVF should we be supporting?
- Question: What back-up approach should we be supporting (e.g., deltas? full back-ups, etc.)?