diff --git a/incubation/openstack-api-extensions/apix-intro-proposal.xml b/incubation/openstack-api-extensions/apix-intro-proposal.xml index 943521a..83620f0 100644 --- a/incubation/openstack-api-extensions/apix-intro-proposal.xml +++ b/incubation/openstack-api-extensions/apix-intro-proposal.xml @@ -39,17 +39,17 @@ the process used to promote API extensions to new features. - Please note that this document is a draft. It + Please note that this document is a draft. It is intended to give developers an opportunity to provide feedback. If you begin implementing against this early access specification, please recognize that it is still subject to change. Comments, feedback, and bug reports are always welcomed; - please submit these in the webhelp discussion forum at: http://docs.openstack.org/. + please submit these in the webhelp discussion forum at: http://docs.openstack.org/.
Intended Audience - This document is intended for software developers who wish either to implement or + This document is intended for software developers who wish either to implement or to consume an extendable OpenStack API. It assumes that the reader has a general - understanding of: + understanding of: ReSTful web services @@ -102,8 +102,8 @@ Chapter 5, Summary - Briefly summarizes the benefits of the extension mechanism and - provides a brief overview of how extensions are used. + Briefly summarizes the benefits of the extension mechanism and + provides a brief overview of how extensions are used. @@ -123,7 +123,7 @@ - Initial draft. + Initial draft. @@ -174,7 +174,7 @@ function normally — this is where extensions come in. - An extension adds capabilities to an API beyond those + An extension adds capabilities to an API beyond those defined in the core. The introduction of new features, MIME types, actions, states, headers, parameters, and resources can all be accomplished by means of extensions to the core API. In order for extensions to work, the core API must be written in such @@ -186,7 +186,7 @@ together form the extension mechanism. It is important that core APIs adhere to this mechanism in order to ensure compatibility as new extensions are defined. Note also that while a core API may be written to allow for - extensibility, the extensions themselves are never part of the core. + extensibility, the extensions themselves are never part of the core.
Relationship to OpenGL @@ -211,15 +211,15 @@ needed to meet the goal of performing at real-time speeds. - Gaining vendor support is challenging because vendors are often in direct + Gaining vendor support is challenging because vendors are often in direct competition with one another. They differentiate themselves by creating innovative new features and by providing niche functionality to their users. Thus, OpenGL was faced with two competing requirements. On the one hand, it needed to abstract away vendor differences in order to provide a stable cross-platform environment to developers. On the other hand, in order to garner vendor support, it needed a method by which vendors could differentiate themselves and provide innovative new features - and niche functionality to their users. - The OpenGL extension mechanism was developed to solve these problems. The + and niche functionality to their users. + The OpenGL extension mechanism was developed to solve these problems. The extension mechanism achieved balance between the two requirements by maintaining the core specification under the direction of the Architecture Review Board while allowing vendors to define extensions to the core OpenGL specification. The core @@ -231,8 +231,8 @@ and many vendors, including NVidia, ATI, Apple, IBM, and Intel, have participated in the process by developing their own custom extensions. Additionally, many key innovations (such as vertex and fragment shaders) have been developed via the - extension process and are now part of the core OpenGL API. - OpenStack, while very different from OpenGL, shares many similar goals and faces + extension process and are now part of the core OpenGL API. + OpenStack, while very different from OpenGL, shares many similar goals and faces many of the same challenges. OpenStack APIs are designed to be open API standards. An important goal is to provide developers with a ubiquitous, stable, any-scale cloud development platform that abstracts away many of the differences between @@ -248,23 +248,23 @@ defined vary drastically, of course, since the nature of the APIs is very different (C versus ReST); however, the manner in which extensions are documented, the way in which vendors are attributed, and the promotion path that an extension follows, all - borrow heavily from OpenGL. + borrow heavily from OpenGL.
Extensions and Versions - Extensions are always interpreted in relation to a version of the core API. In + Extensions are always interpreted in relation to a version of the core API. In other words, from a client's perspective, an extension modifies a particular version of the core API in some way. In reality, an extension may be applicable to several versions of an API at once. For example, a particular extension may continue to be available as a core API moves from one version to another. In fact, different implementations may decide to include support - for an extension at different versions. As explained in - the chapter on "Extension Governance and Promotion", + for an extension at different versions. As explained in + the chapter on "Extension Governance and Promotion", when an extension is defined, the minimal version of the core API that is required to run the extension is specified; implementers are free to support the extension in that version or in a later version of the core. Note, however, that because the extension mechanism allows for promotion, an extension in one version of a core API - may become a standard feature in a later version. + may become a standard feature in a later version. As always, implementers are not required to @@ -272,19 +272,19 @@ core. - Because several versions of the core API may be supported simultaneously, and + Because several versions of the core API may be supported simultaneously, and because each version may offer support for a different set of extensions, clients must be able to detect what versions and extensions are available in a particular deployment. Thus, both extensions and versions are queryable. Issuing a GET on the base URL (/) of the API endpoint returns information about what versions are available. Similarly, issuing a GET on the API's extensions resource (/v1.1/extensions) returns information about what extensions are - available. (See - the chapter on "Extensions and ReST" + available. (See + the chapter on "Extensions and ReST" for details of such requests.) Note that, since extensions modify a particular version of the API, the extensions - resource itself is always accessed at a particular version. - Backward-compatible changes in an API usually require a minor version bump. In an + resource itself is always accessed at a particular version. + Backward-compatible changes in an API usually require a minor version bump. In an extensible API, however, these changes can be brought in as extensions. The net effect is that versions change infrequently and thus provide a stable platform on which to develop. The Policy Review Board (PRB), with the help of project team @@ -295,7 +295,7 @@ extensions can be promoted to standard features, the development of new versions can be influenced significantly by individual developers and the OpenStack client community and is therefore not strictly defined by the PRB. In other words, new - features of a core API may be developed in a bottom-up fashion. + features of a core API may be developed in a bottom-up fashion. That said, not all extensions are destined to be promoted to the next API version. Core APIs always @@ -422,37 +422,37 @@
Versioning Extensions - There is no explicit versioning mechanism for extensions. Nonetheless, there may + There is no explicit versioning mechanism for extensions. Nonetheless, there may be cases in which a developer decides to update an extension after the extension has been released and client support for the extension has been established. In these cases, it is recommended that a new extension be created. The extension may have a name that signifies its relationship to the previous version. For example, a developer may append an integer to the extension name to signify that one extension - updates another: RAX-PIE2 updates RAX-PIE. - Extensions may have dependencies on other extensions. For example, + updates another: RAX-PIE2 updates RAX-PIE. + Extensions may have dependencies on other extensions. For example, RAX-PIE2 may depend on RAX-PIE and may simply add additional capabilities to it. In general, dependencies of this kind are discouraged and implementers should strive to keep extensions independent. That said, extension dependencies allow for the possibility of providing updates to existing extensions even if the original extension is under the control of a different vendor. This is - particularly useful in cases where an existing extension has good client support. + particularly useful in cases where an existing extension has good client support.
Extensions and Pluggability - Core APIs abstract away vendor differences in order to provide a cross-platform + Core APIs abstract away vendor differences in order to provide a cross-platform environment to their clients. For example, a client should be able to interact with an OpenStack load balancing service without worrying about whether the deployment utilizes Zeus, Pound, or HAProxy on the backend. OpenStack implementations strive to support multiple backends out of the box. They do so by employing software drivers. Each driver is responsible for communicating to a specific backend and is in charge - of translating core API requests to it. - The core API contains only those capabilities which are applicable to all + of translating core API requests to it. + The core API contains only those capabilities which are applicable to all backends; however, not all backends are created equal, with each backend offering a distinct set of capabilities. Extensions play a critical role in exposing these capabilities to clients. This is illustrated below. Here, extensions fill in the gap between the common capabilities that the core API provides and the unique capabilities of the Zeus load balancer. In a sense, one can think of extensions as - providing frontends to OpenStack plug-ins. + providing frontends to OpenStack plug-ins.
Extensions and Pluggability @@ -466,8 +466,4 @@
- - - - diff --git a/openstack-compute-api-1.0/src/cs-devguide.xml b/openstack-compute-api-1.0/src/cs-devguide.xml index a261f61..a808a71 100644 --- a/openstack-compute-api-1.0/src/cs-devguide.xml +++ b/openstack-compute-api-1.0/src/cs-devguide.xml @@ -28,7 +28,7 @@ + /> '> ]> @@ -69,7 +69,7 @@ This document is intended for software developers interested in developing applications using the OpenStack Compute Application Programming Interface - (API). + (API). this is a placeholder for the front cover @@ -327,16 +327,16 @@ Servers can occur programmatically via the OpenStack Compute API. - We welcome feedback, comments, and bug reports at bugs.launchpad.net/nova. + We welcome feedback, comments, and bug reports at bugs.launchpad.net/nova.
Intended Audience - This Guide is intended to assist software developers who want to develop + This Guide is intended to assist software developers who want to develop applications using the Rackspace Cloud Servers API. To use the information provided here, you should first have a general understanding of the Rackspace Cloud Servers service and have access to an active Rackspace Cloud Servers account. You should - also be familiar with: + also be familiar with: ReSTful web services @@ -383,8 +383,8 @@ You can download the most current version of this document from the OpenStack Docs website at - http://docs.openstack.org. - For more details about the Cloud Servers service that this API is based upon, please refer to . + For more details about the Cloud Servers service that this API is based upon, please refer to http://www.rackspacecloud.com/cloud_hosting_products/servers. Related documents, including an
- Concepts - To use the Cloud Servers API effectively, you should understand several key concepts: + To use the Cloud Servers API effectively, you should understand several key concepts:
Server @@ -500,9 +499,9 @@ General API Information - The Cloud Servers API is implemented using a ReSTful web service interface. Like + The Cloud Servers API is implemented using a ReSTful web service interface. Like other products in the Rackspace Cloud suite, Cloud Servers shares a common token - authentication system that allows seamless access between products and services. + authentication system that allows seamless access between products and services. All requests to authenticate and operate against Cloud @@ -512,15 +511,15 @@
Authentication - Each ReST request against the Cloud Servers system requires the inclusion of a + Each ReST request against the Cloud Servers system requires the inclusion of a specific authorization token HTTP x-header, defined as X-Auth-Token. Clients obtain this token, along with the Cloud Servers API URL, by first using the Rackspace Cloud Authentication Service and supplying a valid username and API access - key. - The Rackspace Cloud Authentication Service is a ReSTful web service. It is - the entry point to all Rackspace Cloud APIs. - To access the Authentication Service, you must know whether your account is - US-based or UK-based: + key. + The Rackspace Cloud Authentication Service is a ReSTful web service. It is + the entry point to all Rackspace Cloud APIs. + To access the Authentication Service, you must know whether your account is + US-based or UK-based: @@ -537,14 +536,14 @@ Your account may be based in either the US or the UK; this is not determined by your physical location but by the location of the Rackspace retail site which - was used to create your account: + was used to create your account: If your account was created via http://www.rackspacecloud.com, it is a US-based account. - + @@ -594,7 +593,7 @@ X-Auth-Key: a86850deb2742ec3cb41518e26aa2d89 Response - The Cloud Servers API may return any of the HTTP/1.1 response codes defined + The Cloud Servers API may return any of the HTTP/1.1 response codes defined by RFC-2616 Section 10. If authentication is successful, an HTTP status 204 (No Content) is returned with three cloud @@ -607,7 +606,7 @@ X-Auth-Key: a86850deb2742ec3cb41518e26aa2d89 and must include the X-Auth-Token header as noted above. The URLs specified in X-Storage-Url and X-CDN-Management-Url are specific to the Cloud Files product and may be ignored for purposes of - interacting with Cloud Servers. + interacting with Cloud Servers. Authentication Response @@ -841,7 +840,7 @@ X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
Efficient Polling with the <parameter>Changes-Since</parameter> Parameter - The ReST API allows you to poll for the status of certain operations by + The ReST API allows you to poll for the status of certain operations by performing a &GET; on various elements. Rather than re-downloading and re-parsing the full status at each polling interval, your ReST client may use the changes-since parameter to check for changes since a @@ -853,7 +852,7 @@ X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb has changed, only the items changed since the specified time will be returned in the response. For example, performing a &GET; against https://api.servers.rackspacecloud.com/v1.0/224532/servers?changes-since=1244012982 - would list all servers that have changed since Wed, 03 Jun 2009 07:09:42 UTC. + would list all servers that have changed since Wed, 03 Jun 2009 07:09:42 UTC.
@@ -879,7 +878,7 @@ X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb Rate Limits We specify rate limits in terms of - both a human-readable wild-card URI and a machine-processable regular expression. + both a human-readable wild-card URI and a machine-processable regular expression. The regular expression boundary matcher '^' takes effect after the root URI path. For example, the regular expression ^/servers would match the bolded @@ -1165,14 +1164,14 @@ Host: servers.api.rackspacecloud.com/v1.0/ If there is a discrepancy between the two specifications, the WADL is authoritative as it contains the most accurate and up-to-date description of the - API service. + API service.
Faults - When an error occurs, the system will return an HTTP error response code denoting + When an error occurs, the system will return an HTTP error response code denoting the type of error. The system will also return additional information about the - fault in the body of the response. + fault in the body of the response. Fault Response: XML @@ -1185,11 +1184,11 @@ Host: servers.api.rackspacecloud.com/v1.0/ - The error code is returned in the body of the response for convenience. The + The error code is returned in the body of the response for convenience. The message section returns a human-readable message that is appropriate for display to - the end user. The details section is optional and may contain information—for example, a stack trace—to + the end user. The details section is optional and may contain information—for example, a stack trace—to assist in tracking down an error. The detail section may or may not be - appropriate for display to an end user. + appropriate for display to an end user. The root element of the fault (e.g. cloudServersFault) may change depending on the type of error. The @@ -1801,13 +1800,13 @@ Host: servers.api.rackspacecloud.com/v1.0/ This operation does not require a request body. - Addresses List Response: XML + Addresses List Response: XML - Addresses List Response: JSON + Addresses List Response: JSON @@ -1889,7 +1888,7 @@ Host: servers.api.rackspacecloud.com/v1.0/ badRequest (400), overLimit (413) - This operation does not require a request body. + This operation does not require a request body. Private Addresses List Response: XML @@ -2099,13 +2098,13 @@ Host: servers.api.rackspacecloud.com/v1.0/ equivalent of power cycling the server. - Action Reboot: XML + Action Reboot: XML - Action Reboot: JSON + Action Reboot: JSON @@ -2174,7 +2173,7 @@ Host: servers.api.rackspacecloud.com/v1.0/ addresses will remain the same. - Action Rebuild: XML + Action Rebuild: XML @@ -2466,7 +2465,7 @@ Host: servers.api.rackspacecloud.com/v1.0/ This operation does not require a request body. - Flavors List Response: XML (detail) + Flavors List Response: XML (detail) @@ -2520,7 +2519,7 @@ Host: servers.api.rackspacecloud.com/v1.0/ - Flavor Details Response: JSON + Flavor Details Response: JSON diff --git a/openstack-compute-api-1.0/src/samples/addip.xml b/openstack-compute-api-1.0/src/samples/addip.xml index df8ed78..e62e751 100644 --- a/openstack-compute-api-1.0/src/samples/addip.xml +++ b/openstack-compute-api-1.0/src/samples/addip.xml @@ -1,4 +1,4 @@ - + diff --git a/openstack-compute-api-1.0/src/samples/reboot.xml b/openstack-compute-api-1.0/src/samples/reboot.xml index b000ae6..488a37f 100644 --- a/openstack-compute-api-1.0/src/samples/reboot.xml +++ b/openstack-compute-api-1.0/src/samples/reboot.xml @@ -1,4 +1,4 @@ - \ No newline at end of file + diff --git a/openstack-compute-api-1.0/src/samples/rebuild.xml b/openstack-compute-api-1.0/src/samples/rebuild.xml index aed0199..8b4fe0f 100644 --- a/openstack-compute-api-1.0/src/samples/rebuild.xml +++ b/openstack-compute-api-1.0/src/samples/rebuild.xml @@ -1,4 +1,4 @@ - + diff --git a/openstack-compute-api-1.0/src/samples/resize.xml b/openstack-compute-api-1.0/src/samples/resize.xml index ed38aba..ad4c65a 100644 --- a/openstack-compute-api-1.0/src/samples/resize.xml +++ b/openstack-compute-api-1.0/src/samples/resize.xml @@ -1,4 +1,4 @@ - \ No newline at end of file + diff --git a/openstack-compute-api-1.0/src/samples/server-post-resp.xml b/openstack-compute-api-1.0/src/samples/server-post-resp.xml index d35a9af..3112ce6 100644 --- a/openstack-compute-api-1.0/src/samples/server-post-resp.xml +++ b/openstack-compute-api-1.0/src/samples/server-post-resp.xml @@ -1,11 +1,11 @@ + id="1235" name="new-server-test" + imageId="1" flavorId="1" + hostId="e4d909c290d0fb1ca068ffaddf22cbd0" + progress="0" status="BUILD" + adminPass="GFf1j9aP"> Apache1 @@ -17,4 +17,4 @@ - \ No newline at end of file + diff --git a/openstack-compute-api-1.0/src/samples/shareip.xml b/openstack-compute-api-1.0/src/samples/shareip.xml index ccbed21..b6ce1d8 100644 --- a/openstack-compute-api-1.0/src/samples/shareip.xml +++ b/openstack-compute-api-1.0/src/samples/shareip.xml @@ -1,4 +1,4 @@ - + diff --git a/openstack-compute-api-1.0/src/samples/snapshot.xml b/openstack-compute-api-1.0/src/samples/snapshot.xml index 06f2289..fa1c67c 100644 --- a/openstack-compute-api-1.0/src/samples/snapshot.xml +++ b/openstack-compute-api-1.0/src/samples/snapshot.xml @@ -1,4 +1,4 @@ - \ No newline at end of file + diff --git a/openstack-compute-api-2/src/os-compute-devguide.xml b/openstack-compute-api-2/src/os-compute-devguide.xml index 62e8028..92dae3b 100755 --- a/openstack-compute-api-2/src/os-compute-devguide.xml +++ b/openstack-compute-api-2/src/os-compute-devguide.xml @@ -1899,7 +1899,7 @@ Host: servers.api.openstack.org/v2/ BUILD &ARROW; - ERROR (on error) + ERROR (on error) @@ -2321,7 +2321,7 @@ Host: servers.api.openstack.org/v2/ edit the server name, the server host name does not change. Also, server names are not guaranteed to - be unique. + be unique. @@ -2515,7 +2515,7 @@ Host: servers.api.openstack.org/v2/ ACTIVE &ARROW; PASSWORD &ARROW; - ERROR (on error) + ERROR (on error) @@ -2523,7 +2523,7 @@ Host: servers.api.openstack.org/v2/ ERROR &ARROW; PASSWORD &ARROW; ACTIVE (password reset - after error) + after error) @@ -2620,7 +2620,7 @@ Host: servers.api.openstack.org/v2/ ACTIVE &ARROW; REBOOT &ARROW; ACTIVE (soft - reboot) + reboot) @@ -2628,7 +2628,7 @@ Host: servers.api.openstack.org/v2/ ACTIVE &ARROW; HARD_REBOOT &ARROW; ACTIVE (hard - reboot) + reboot) @@ -2687,11 +2687,11 @@ Host: servers.api.openstack.org/v2/ This operation does not return a response body. - Action Reboot Request: XML + Action Reboot Request: XML - Action Reboot Request: JSON + Action Reboot Request: JSON
@@ -2748,7 +2748,7 @@ Host: servers.api.openstack.org/v2/ ACTIVE &ARROW; REBUILD &ARROW; - ERROR (on error) + ERROR (on error) @@ -2835,7 +2835,7 @@ Host: servers.api.openstack.org/v2/ - Action Rebuild Request: XML + Action Rebuild Request: XML @@ -3027,7 +3027,7 @@ Host: servers.api.openstack.org/v2/ VERIFY_RESIZE &ARROW; - ERROR (on error) + ERROR (on error) @@ -3110,7 +3110,7 @@ Host: servers.api.openstack.org/v2/ VERIFY_RESIZE &ARROW; REVERT_RESIZE &ARROW; - ERROR (on error) + ERROR (on error) @@ -3199,7 +3199,7 @@ Host: servers.api.openstack.org/v2/ SAVING &ARROW; - ERROR (on error) + ERROR (on error) @@ -3380,7 +3380,7 @@ Host: servers.api.openstack.org/v2/ This operation does not require a request body. - Flavors List Response: XML (detail) + Flavors List Response: XML (detail) @@ -3436,7 +3436,7 @@ Host: servers.api.openstack.org/v2/ - Flavor Details Response: JSON + Flavor Details Response: JSON
@@ -3467,7 +3467,7 @@ Host: servers.api.openstack.org/v2/ status=imageStatus& changes-since=dateTime& marker=markerID&limit=int& - type=(BASE|SERVER) + type=(BASE|SERVER) Lists IDs, names, and links for all available images. @@ -3479,7 +3479,7 @@ Host: servers.api.openstack.org/v2/ status=imageStatus& changes-since=dateTime& marker=markerID&limit=int& - type=(BASE|SERVER) + type=(BASE|SERVER) Lists all details for all available images. @@ -3757,11 +3757,11 @@ Host: servers.api.openstack.org/v2/ This operation does not require a request body. - Metadata List Response: XML + Metadata List Response: XML - Metadata List Response: JSON + Metadata List Response: JSON
@@ -3855,20 +3855,20 @@ Host: servers.api.openstack.org/v2/ queried through the maxImageMeta absolute limit. - Set Metadata Request: XML + Set Metadata Request: XML - Set Metadata Request: JSON + Set Metadata Request: JSON - Set Metadata Response: XML + Set Metadata Response: XML - Set Metadata Response: JSON + Set Metadata Response: JSON @@ -3962,20 +3962,20 @@ Host: servers.api.openstack.org/v2/ an image may be queried through the maxImageMeta absolute limit. - Update Metadata Request: XML + Update Metadata Request: XML - Update Metadata Request: JSON + Update Metadata Request: JSON - Update Metadata Response: XML + Update Metadata Response: XML - Update Metadata Response: JSON + Update Metadata Response: JSON @@ -4028,11 +4028,11 @@ Host: servers.api.openstack.org/v2/ This operation does not require a request body. - Metadata Item Response: XML + Metadata Item Response: XML - Metadata Item Response: JSON + Metadata Item Response: JSON @@ -4121,20 +4121,20 @@ Host: servers.api.openstack.org/v2/ of key-value pairs for an image may be queried through the maxImageMeta absolute limit. - Set Metadata Item Request: XML + Set Metadata Item Request: XML - Set Metadata Item Request: JSON + Set Metadata Item Request: JSON - Set Metadata Item Response: XML + Set Metadata Item Response: XML - Set Metadata Item Response: JSON + Set Metadata Item Response: JSON diff --git a/openstack-compute-api-2/src/samples/ext-server.xml b/openstack-compute-api-2/src/samples/ext-server.xml index df96d0c..08d6c70 100644 --- a/openstack-compute-api-2/src/samples/ext-server.xml +++ b/openstack-compute-api-2/src/samples/ext-server.xml @@ -3,7 +3,7 @@ xmlns:atom="http://www.w3.org/2005/Atom" xmlns:aide="http://docs.rackspacecloud.com/servers/api/ext/aide/v1.0" id="52415800-8b69-11e0-9b19-734f000004d2" name="sample-server" - flavorRef="https://servers.api.rackspacecloud.com/v2/32278/flavors/52415800-8b69-11e0-9b19-734f1195ff37" + flavorRef="https://servers.api.rackspacecloud.com/v2/32278/flavors/52415800-8b69-11e0-9b19-734f1195ff37" status="BUILD" updated="2010-10-10T12:00:00Z" created="2010-08-10T12:00:00Z" diff --git a/openstack-compute-api-2/src/samples/image-fault.xml b/openstack-compute-api-2/src/samples/image-fault.xml index 6c1b95d..3b70de5 100644 --- a/openstack-compute-api-2/src/samples/image-fault.xml +++ b/openstack-compute-api-2/src/samples/image-fault.xml @@ -11,10 +11,10 @@ An internal error occured
Error details
- - diff --git a/openstack-compute-api-2/src/samples/image-meta-page1.xml b/openstack-compute-api-2/src/samples/image-meta-page1.xml index 6732d69..085cf3a 100644 --- a/openstack-compute-api-2/src/samples/image-meta-page1.xml +++ b/openstack-compute-api-2/src/samples/image-meta-page1.xml @@ -7,11 +7,11 @@ 1.5 Gold - - diff --git a/openstack-compute-api-2/src/samples/image-simple.xml b/openstack-compute-api-2/src/samples/image-simple.xml index 0b43eaa..a187665 100644 --- a/openstack-compute-api-2/src/samples/image-simple.xml +++ b/openstack-compute-api-2/src/samples/image-simple.xml @@ -4,7 +4,7 @@ xmlns:atom="http://www.w3.org/2005/Atom" id="52415800-8b69-11e0-9b19-734f5736d2a2" name="My Server Backup"> - - - diff --git a/openstack-compute-api-2/src/samples/images-page1-sp.xml b/openstack-compute-api-2/src/samples/images-page1-sp.xml index 474af3b..0373fa4 100644 --- a/openstack-compute-api-2/src/samples/images-page1-sp.xml +++ b/openstack-compute-api-2/src/samples/images-page1-sp.xml @@ -15,10 +15,10 @@ - - diff --git a/openstack-compute-api-2/src/samples/images-page2.xml b/openstack-compute-api-2/src/samples/images-page2.xml index e208e0f..c1cfc1f 100644 --- a/openstack-compute-api-2/src/samples/images-page2.xml +++ b/openstack-compute-api-2/src/samples/images-page2.xml @@ -2,7 +2,7 @@ - diff --git a/openstack-compute-api-2/src/samples/images-page3.xml b/openstack-compute-api-2/src/samples/images-page3.xml index 2793479..831a2e2 100644 --- a/openstack-compute-api-2/src/samples/images-page3.xml +++ b/openstack-compute-api-2/src/samples/images-page3.xml @@ -3,7 +3,7 @@ xmlns:atom="http://www.w3.org/2005/Atom"> - diff --git a/openstack-compute-api-2/src/samples/images.xml b/openstack-compute-api-2/src/samples/images.xml index 2a277de..4ab801f 100644 --- a/openstack-compute-api-2/src/samples/images.xml +++ b/openstack-compute-api-2/src/samples/images.xml @@ -36,10 +36,10 @@ rel="bookmark" href="http://servers.api.openstack.org/1234/servers/52415800-8b69-11e0-9b19-734f335aa7b3"/> - - diff --git a/openstack-compute-api-2/src/samples/rebuild-resp.xml b/openstack-compute-api-2/src/samples/rebuild-resp.xml index d5d8b63..354df63 100644 --- a/openstack-compute-api-2/src/samples/rebuild-resp.xml +++ b/openstack-compute-api-2/src/samples/rebuild-resp.xml @@ -1,7 +1,7 @@ - - - \ No newline at end of file + diff --git a/openstack-compute-api-2/src/samples/server-post-req-bad-file-length.xml b/openstack-compute-api-2/src/samples/server-post-req-bad-file-length.xml index 8c09d2a..a7e88d9 100644 --- a/openstack-compute-api-2/src/samples/server-post-req-bad-file-length.xml +++ b/openstack-compute-api-2/src/samples/server-post-req-bad-file-length.xml @@ -1,5 +1,5 @@ - diff --git a/openstack-compute-api-2/src/samples/server-put-resp-ad.xml b/openstack-compute-api-2/src/samples/server-put-resp-ad.xml index e9662e7..88f47cf 100644 --- a/openstack-compute-api-2/src/samples/server-put-resp-ad.xml +++ b/openstack-compute-api-2/src/samples/server-put-resp-ad.xml @@ -1,7 +1,7 @@ - - diff --git a/openstack-compute-api-2/src/samples/servers.xml b/openstack-compute-api-2/src/samples/servers.xml index 162c3b0..9647354 100644 --- a/openstack-compute-api-2/src/samples/servers.xml +++ b/openstack-compute-api-2/src/samples/servers.xml @@ -3,7 +3,7 @@ xmlns:atom="http://www.w3.org/2005/Atom"> - - diff --git a/openstack-compute-api-2/src/samples/versions_bad_link.xml b/openstack-compute-api-2/src/samples/versions_bad_link.xml index 39f501f..dc0ebfa 100644 --- a/openstack-compute-api-2/src/samples/versions_bad_link.xml +++ b/openstack-compute-api-2/src/samples/versions_bad_link.xml @@ -5,36 +5,36 @@ - + - + - + - + - + - + - + diff --git a/openstack-compute-api-2/src/section_concepts.xml b/openstack-compute-api-2/src/section_concepts.xml index 8cfac65..42e3682 100644 --- a/openstack-compute-api-2/src/section_concepts.xml +++ b/openstack-compute-api-2/src/section_concepts.xml @@ -5,7 +5,7 @@ - + GET'> PUT'> @@ -23,19 +23,19 @@ Concepts To use the OpenStack Compute API effectively, you should - understand several key concepts: + understand several key concepts: Server A virtual machine (VM) instance in the compute system. Flavor and image are requisite elements when - creating a server. + creating a server. Flavor An available hardware configuration for a server. Each flavor has a unique combination of disk space, - memory capacity and priority for CPU time. + memory capacity and priority for CPU time. Image @@ -45,7 +45,7 @@ from cloud servers you have launched. These custom images are useful for backup purposes or for producing “gold” server images if you plan to deploy a - particular server configuration frequently. + particular server configuration frequently. Reboot @@ -57,13 +57,13 @@ virtualization platform should ensure that the reboot action has completed successfully even in cases in which the underlying domain/VM is paused or - halted/stopped. + halted/stopped. Rebuild Use this function to remove all data on the server and replaces it with the specified image. Server ID and IP - addresses remain the same. + addresses remain the same. Resize @@ -73,8 +73,8 @@ time to allow rollback if there is a problem. All resizes should be tested and explicitly confirmed, at which time the original server is removed. All resizes - are automatically confirmed after 24 hours if you do not - confirm or revert them. + are automatically confirmed after 24 hours if you do not + confirm or revert them.