Notes

%common; ]> The account ID of the owner of the specified instance. The instance ID for the specified database instance. The name for the specified database. The name for the specified user. The flavor ID for the specified flavor. Returns detailed information about the specified version of the API. Reviewer: in the DNS project, we have been requested by the customer to provide a table of parameters (should be pulled automatically if parms defined in wadl) and a table of attributes (for calls that allow detailed info about the object created to be specified. No doubt our DB customers will want this too. Reviewer: These tables probably need 4 columns: name; parameter type: e.g. template, query, etc.; data type: string, etc.; required?; description. This operation returns detailed information about the specified version of the API. The following examples show the List Version Details requests: The following examples show the List Version Details responses: &commonFaults; &getFaults; Lists information about all versions of the API. This operation lists information about all versions of the API. The following examples show the List Versions requests: The following examples show the List Versions responses: &commonFaults; &getFaults; Creates a new database instance. This operation asynchronously provisions a new database instance. This call requires the user to specify a flavor and a volume size. The service then provisions the instance with the requested flavor and sets up a volume of the specified size, which is the storage for the database instance. Notes You can create only one database instance per POST request. You can create a database instance with one or more databases, and users associated to those databases. The default binding for the MySQL instance is port 3306. Database instances are directly accessible only on the internal ServiceNet network and using a Cloud resource within the same regional datacenter. For example, a database instance in DFW can only be accessed by a Cloud Server in DFW. For details and information about using a public Cloud Load Balancer to allow access to your database instance, refer to for details. The following table lists the required and optional attributes for Create Instance:

Required and Optional Attributes for Create Instance
Applies To	Name	Description	Required
Instance	flavorRef	Reference (href) to a flavor as specified in the response from the List Flavors API call. This is the actual URI as specified by the href field in the link. For example, in the following List Flavors response, the link to flavor id 1 is specified as "https://ord.databases.api.rackspacecloud.com/v1.0/1234/flavors/1". Rather than the flavor URI, you can also pass the flavor id (integer) as the value for flavorRef. For example, the flavor id for the flavor URI shown above is "1". Refer to for details.	Yes
	(volume) size	Specifies the volume size in gigabytes (GB). The value specified must be between 1 and 50.	Yes
	name	Name of the instance to create. The length of the name is limited to 255 characters and any characters are permitted.	No
Database	name	Specifies database names for creating databases on instance creation. Refer to for the required xml/json format.	No
	character_set	Set of symbols and encodings. The default character set is `utf8`.	No
	collate	Set of rules for comparing characters in a character set. The default value for collate is `utf8_general_ci`.	No
User	name	Specifies user name for the database on instance creation. Refer to for the required xml/json format.	No
	password	Specifies password for those users on instance creation. Refer to for the required xml/json format.	No
	(database) name	Specifies names of databases that those users can access on instance creation. Refer to for the required xml/json format.	No

Refer to for a list of possible database instance statuses that may be returned. The following examples show the Create Database Instance requests and responses: For convenience, notice in the response examples above that resources contain links to themselves. This allows a client to easily obtain resource URIs rather than to construct them. There are two kinds of link relations associated with resources. A self link contains a versioned link to the resource. These links should be used in cases where the link will be followed immediately. A bookmark link provides a permanent link to a resource that is appropriate for long term storage. &commonFaults; &getFaults; Deletes the specified database instance. This operation deletes the specified database instance, including any associated data. Refer to for a list of possible database instance statuses that may be returned. This operation does not delete any read slaves. Reviewer: please provide a description of read slaves that I can add to the previous note. This operation is not allowed when the instance state is either REBUILDING or BUILDING. The following examples show the Delete Database Instance requests: &commonFaults; The following examples show the Delete Database Instance responses: &getFaults; Lists the status and information for all database instances. This operation lists the status and information for all database instances. Refer to for a list of possible database instance statuses that may be returned. The following examples show the List All Database Instances Detail requests: The following examples show the List All Database Instances responses: &commonFaults; &getFaults; Lists status and details for a specified database instance. This operation lists the status and details of the specified database instance. This operation lists the volume size in gigabytes (GB) and the approximate GB used. After instance creation, the used size of your volume will be greater than 0. This is expected and due to the automatic creation of non-empty transaction logs for mysql optimization. The used attribute is not returned in the response when the status for the instance is BUILD, REBOOT, or RESIZE. Refer to for a list of possible database instance statuses that may be returned. The list operations return a DNS-resolvable hostname associated with the database instance instead of an IP address. Since the hostname always resolves to the correct IP address of the database instance, this relieves the user from the task of maintaining the mapping. Note that although the IP address may likely change on resizing, migrating, and so forth, the hostname always resolves to the correct database instance. The following examples show the List Database Instance Status and Details requests: The following examples show the List Database Instance Status and Details responses: &commonFaults; &getFaults; Restart the database service on the instance. The restart operation will restart only the MySQL Instance. Restarting MySQL will erase any dynamic configuration settings that you have made within MySQL. The MySQL service will be unavailable until the instance restarts. This operation returns a 202 Accepted response. The following examples show the Restart Instance requests: The following examples show the Restart Instance responses: &commonFaults; &getFaults; &postPutFaults; Resize the memory of the instance. This operation changes the memory size of the instance, assuming a valid flavorRef is provided. Restarts MySQL in the process. The following examples show the Resize Instance requests: The following examples show the Resize Instance responses: &commonFaults; &getFaults; &postPutFaults; Resize the volume attached to the Instance. This operation supports resizing the attached volume for an instance. It supports only increasing the volume size and does not support decreasing the size. The volume size is in gigabytes (GB) and must be an integer. You cannot increase the volume to a size larger than the API volume size limit specifies. This operation returns a 202 Accepted response. The following examples show the Resize Instance Volume requests: The following examples show the Resize Instance Volume responses: &commonFaults; &getFaults; &postPutFaults; Creates a new database within the specified instance. This operation creates a new database within the specified instance. The name of the database is a required attribute. The following additional attributes can be specified for each database: collate and character_set.

Required and Optional Attributes for Create Database
Name	Description	Required
name	Specifies the database name for creating the database. Refer to the request examples for the required xml/json format.	Yes
character_set	Set of symbols and encodings. The default character set is `utf8`.	No
collate	Set of rules for comparing characters in a character set. The default value for collate is `utf8_general_ci`.	No

See the MySQL documentation for information about supported character sets and collations at http://dev.mysql.com/doc/refman/5.1/en/charset-mysql.html. The following database names are reserved and cannot be used for creating databases: lost+found, information_schema, and mysql. Refer to the following tables for information about characters that are valid/invalid for creating database names.

Valid Characters That Can Be Used in a Database Name
Character
Letters (upper and lower cases allowed)
Numbers
'@', '?', '#', and spaces are allowed, but not at the beginning and end of the database name
'_' is allowed anywhere in the database name

Characters That Cannot Be Used in a Database Name
Character
Single quotes
Double quotes
Back quotes
Semicolons
Commas
Backslashes
Forwardslashes

Length Restrictions for Database Name
Restriction	Value
Database-name maximum length	64

The following examples show the Create Database requests: The following examples show the Create Database responses: &commonFaults; &getFaults; Lists databases for the specified instance. This operation lists the databases for the specified instance. This operation returns only the user-defined databases, not the system databases. The system databases (mysql, information_schema, lost+found) can only be viewed by a database administrator. The following examples show the List Databases for Instance requests: The following examples show the List Databases for Instance responses: &commonFaults; &getFaults; Deletes the specified database. This operation deletes the requested database within the specified database instance. Note that all data associated with the database is also deleted. The following examples show the Delete Database requests: The following examples show the Delete Database responses: &commonFaults; &getFaults; Creates a user for the specified database instance. This operation asynchronously provisions a new user for the specified database instance based on the configuration defined in the request object. Once the request is validated and progress has started on the provisioning process, a 202 Accepted response object is returned. Writer: please add the following note back into the doc once the List User Details call is added back into the API: Using the identifier, the caller can check on the progress of the operation by performing a GET on users/name (for more details on this operation see the "List User Details" section of this document). If the corresponding request cannot be fulfilled due to insufficient or invalid data, an HTTP 400 "Bad Request" error response is returned with information regarding the nature of the failure. Failures in the validation process are non-recoverable and require the caller to correct the cause of the failure and POST the request again. The following table lists the required attributes for Create User. Refer to the request examples for the required xml/json format:

Required Attributes for Create User
Applies To	Name	Description	Required
User	name	Name of the user for the database.	Yes
	password	User password for database access.	Yes
	(database) name	Name of the database that the user can access. One or more database names must be specified.	No

Notes A user is granted all privileges on the specified databases. The following user name is reserved and cannot be used for creating users: root. Refer to the following tables for information about characters that are valid/invalid for creating database names, user names, and passwords.

Valid Characters That Can Be Used in a Database Name, User Name, and Password
Character
Letters (upper and lower cases allowed)
Numbers
'@', '?', '#', and spaces are allowed, but not at the beginning and end of the database name, user name, and password
"_" is allowed anywhere in the database name, user name, and password

Characters That Cannot Be Used in a Database Name, User Name, and Password
Character
Single quotes
Double quotes
Back quotes
Semicolons
Commas
Backslashes
Forwardslashes
Spaces at the front or end of the user name or password

Length Restrictions for Database Name, User Name, and Password
Restriction	Value
Database name maximum length	64
User name maximum length	16
Password maximum length	unlimited (no restrictions)

The following examples show the Create User requests: The following examples show the Create User responses: &commonFaults; &getFaults; Lists the users in the specified database instance. This operation lists the users in the specified database instance, along with the associated databases for that user. This operation does not return the system users (database administrators that administer the health of the database). Also, this operation returns the "root" user only if "root" user has been enabled. The following notes apply to MySQL users: User names can be up to 16 characters long. When you create accounts with INSERT, you must use FLUSH PRIVILEGES to tell the server to reload the grant tables. For additional information, refer to: http://dev.mysql.com/doc/refman/5.1/en/user-account-management.html The following examples show the List Users in Database Instance requests: The following examples show the List Users in Database Instance responses: &commonFaults; &getFaults; Deletes the user identified by {name} for the specified database instance. This operation deletes the specified user for the specified database instance. There is a bug in a python library that Rackspace is using that may cause incorrect user deletions to occur if a period (.) is used in the user name. In this case, the user name is truncated to remove the portion of the name from the period to the end, leaving only the portion from the beginning up to the period. For example, for a user named "my.userA", the bug would truncate the user name to "my", and if the user "my" exists, that user will be incorrectly deleted. To avoid the problem, do not use periods in user names. The following examples show the Delete User requests: The following examples show the Delete User responses: &commonFaults; &getFaults; Enables the root user for the specified database instance and returns the root password. This operation enables login from any host for the root user and provides the user with a generated root password. Changes you make as a root user may cause detrimental effects to the database instance and unpredictable behavior for API operations. When you enable the root user, you accept the possibility that we will not be able to support your database instance. While enabling root does not prevent us from a “best effort” approach to helping you if something goes wrong with your instance, we cannot ensure that we will be able to assist you if you change core MySQL settings. These changes can be (but are not limited to) turning off binlogs, removing users that we use to access your instance, and so forth. The following examples show the Enable Root User requests: The following examples show the Enable Root User responses: &commonFaults; &getFaults; Returns true if root user is enabled for the specified database instance or false otherwise. This operation checks an active specified database instance to see if root access is enabled. It returns True if root user is enabled for the specified database instance or False otherwise. The following examples show the Check Root User Access requests: The following examples show the Check Root User Access responses: &commonFaults; &getFaults; Lists information for all available flavors. This operation lists information for all available flavors. This resource is identical to the flavors found in the OpenStack Nova API, but without the disk property. Reviewer: please check that the xml example below is now correct. Previously it was reported to be incorrect. The following examples show the List Flavors requests: The following examples show the List Flavors responses: &commonFaults; &getFaults; Lists all flavor information about the specified flavor ID. This operation lists all information for the specified flavor ID with details of the RAM. This resource is identical to the flavors found in the OpenStack Nova API, but without the disk property. The flavorId parameter should be an integer. If a floating point value is used for the flavorId parameter, the decimal portion is truncated and the integer portion is used as the value of the flavorId. Writer: need to confirm that this behavior is not changed in subsequent releases, and if it is prevented, remove the Note above. The following examples show the List Flavor By ID requests: The following examples show the List Flavor By ID responses: &commonFaults; &getFaults;