The Jira issue associated with this design spec https://issues.apache.org/jira/browse/CLOUDSTACK-739
What branch is this work being done inA new branch will be created off master soon for this work. Will update the branch details once started on it.
State the purpose of the document; something like: this is functional specificationS of feature "..." which has Jira ID CS-xyzw
References
relevant links
Document History
Glossary
Feature Specifications
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, hypervisros
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)
Use cases
put the relevant use case/stories to explain how the feature is going to be used/work
Architecture and Design description
discussion of alternatives amongst design ideas, their resources/time tradeoffs and limitations. Explain why a certain design idea is chosen over others
highlight architectural patterns being used (queues, async/sync, state machines, etc)
talk about main algorithms used
explain what components are being changed and what the dependent components are
regarding database: talk about tables being added/modified
performance implications: what are the improvements or risks introduced to capacity, response time, resources usage and other relevant KPIs
preferably show class diagrams, sequence diagrams and state diagrams
if possible, publish signatures of all methods classes and interfaces implement, and the explain the object information of different classes
Web Services APIs
As part of cloud orchestration there is always a need for cloud admins and users to be able to judiciously place the VMs to ensure better availability of their service. Cloudstack API ‘deployVirtualMachine’ lets you specify the compute/disk tags to choose a specific compute host/storage during VM placement.
But currently, there is no way for a user to let CloudStack know how to place a certain VM in relationship to other already existing VMs in the account.
Following are some real life use cases that indicate the need of a mechanism to enable users specify inter-VM placement strategy.
Use Cases:
To address this problem, we will introduce the Affinity Groups feature.
The highlights of the feature include:
The scope of this feature consists of following requirements:
Feature Assumptions
UI/UX Requirements
Admin
User
The high level functional breakdown of the feature is as follows:
Following are the API additions and changes.
CreateAffinityGroup API
This is a new user API to create affinity groups for the account. Parameters include:
a) AccountName
b) DomainId
c) Name
d) Type (affinity/anti-affinity)
e) Description
ListAffinityGroups API
This is a new user API to list affinity groups.Parameters include:
a) Affinity group Id
b) Affinity group Name
c) VM Id
d) AccountName and DomainId
DeleteAffinityGroup API
This is a new user API to delete affinity groups. Parameters include:
a) Affinity group Id
b) Affinity group Name
c) VM Id
d) AccountName and DomainId
UpdateVMAffinityGroup API
This is a new user API to update the affinity groups assocaited with the VM. Parameters include:
a) List of Affinity group Ids OR
b) List of Affinity group Name
c) VM Id
DeployVirtualMachine API
User can set a list of affinity group Ids OR names during a VM deployment. Additional parameters:
a) affinitygroupids
b) affinitygroupnames
ListAffinityGroupTypes API
Lists the affinity/ anti-affinity types available in the zone.
a) zoneIdlist changes to existing web services APIs and new APIs introduced with signatures and throughout documentation
Appendix A:
Appendix B: