DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Status: Work in Progress
This document is currently being updated as part of the Object Name Convention initiative.
Content and examples may change.
This page defines the Title Case Convention for CloudStack Object Types, provides context on where and when to use Title Case, and lists all official Object Types recognized in the platform.
The goal is to make references to key CloudStack objects consistent, readable, and clear, especially in user-facing text, logs, and documentation.
We are standardizing how Object Types are referenced in Apache CloudStack code, logs, API documentation, and developer communication.
Historically, Object Type names (e.g. "instance", "network", "account") have been written inconsistently across code, logs, and API responses. For example, developers may refer to a "virtual machine", "VM", or "instance" interchangeably.
To improve clarity and consistency:
The Title Case Convention ensures that when a word refers to a CloudStack Object Type, it is written as a proper noun (e.g. Instance, Network, User). When used in a generic or non-object sense, it remains lowercase.
The following are the canonical CloudStack Object Types that should always appear in Title Case when referring to CloudStack model entities.
| Object Type | Description |
|---|---|
| Instance | Represents a virtual machine provisioned and managed by CloudStack. Formerly referred to as “Virtual Machine” or “VM.” Instances are created from Templates and run on hypervisors. |
| Network | Logical networking entity that defines connectivity between Instances, Routers, and other components. Includes isolated, shared, and system networks. |
| User | Represents an individual identity within an Account. Each User has unique credentials and access rights. |
| Account | Represents a CloudStack account that owns Users, Instances, Networks, and other resources. |
| Template | A base image used to deploy Instances. |
| Snapshot | A point-in-time copy of a Volume. |
Note: API calls (e.g. listVirtualMachines, deployVirtualMachine) retain the older naming for compatibility.
When writing or updating log messages, always use the correct Object Type name and capitalization.
// Incorrect
LOGGER.info("Failed to start virtual machine for account: " + accountId);
// Correct
LOGGER.info("Failed to start Instance for Account: " + accountId);
Ensure all API parameter and response field descriptions use the proper Object Type name and Title Case.
///////////////////////////////////////////////////// //////////////// API parameters ///////////////////// ///////////////////////////////////////////////////// // Incorrect @Parameter(name = ApiConstants.ACCOUNT, type = CommandType.LONG, description = "the account that owns this network.") private Long account; // Correct @Parameter(name = ApiConstants.ACCOUNT, type = CommandType.LONG, description = "The Account that owns this Network.") private Long account;
| Before | After |
|---|---|
| “the account that owns this network” | "The Account that owns this Network." |
| "Deploys a new virtual machine." | "Deploys a new Instance." |
Use Title Case when describing Object relationships or model entities.
/** * Associates the Network with an Account and allocates IP addresses for Instances. */
Acronyms used in object names, UI labels, API field descriptions, and user-facing documentation must be written in UPPERCASE. This applies to commonly used technical acronyms such as:
Examples:
Note:
This rule applies to object naming, UI text, and documentation.
It does not override the CloudStack coding-style guideline that discourages uppercase acronyms in Java variable and method names.
All references to CloudStack-managed objects in user-facing content; including CWIKI documentation, Admin UI strings, and API reference docs, should use the canonical Title Case name.
Always verify whether the term refers to a CloudStack Object Type before applying Title Case.
Do not change API names or parameters that are public-facing or backward-compatible (e.g., deployVirtualMachine); only update descriptions, logs, and documentation.
Use Instance instead of Virtual Machine or VM in all new code, messages, and documentation.
Community feedback is welcome via mailing list or JIRA.