Remove extra whitespace

This removes extra whitespace that is not needed

Change-Id: If3ab21b7d13a378e254df408fab33b12cf794dad
This commit is contained in:
Andreas Jaeger 2013-12-25 20:16:11 +01:00
parent 526db7f1b6
commit 371ad9e981
29 changed files with 165 additions and 170 deletions

View File

@ -39,17 +39,17 @@
the process used to promote API extensions to new features.
</para>
<warning security="draft">
<para> Please note that this document is a <emphasis role="strong">draft</emphasis>. It
<para>Please note that this document is a <emphasis role="strong">draft</emphasis>. 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: <link xlink:href="http://docs.openstack.org/">http://docs.openstack.org/</link>. </para>
please submit these in the webhelp discussion forum at: <link xlink:href="http://docs.openstack.org/">http://docs.openstack.org/</link>.</para>
</warning>
<section>
<title>Intended Audience</title>
<para> This document is intended for software developers who wish either to implement or
<para>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: </para>
understanding of:</para>
<itemizedlist spacing="compact">
<listitem>
<para>ReSTful web services</para>
@ -102,8 +102,8 @@
<varlistentry>
<term><phrase security="draft">Chapter 5, <firstterm>Summary</firstterm></phrase></term>
<listitem>
<para> Briefly summarizes the benefits of the extension mechanism and
provides a brief overview of how extensions are used. </para>
<para>Briefly summarizes the benefits of the extension mechanism and
provides a brief overview of how extensions are used.</para>
</listitem>
</varlistentry>
</variablelist>
@ -123,7 +123,7 @@
<td colspan="4">
<itemizedlist spacing="compact">
<listitem>
<para> Initial draft. </para>
<para>Initial draft.</para>
</listitem>
</itemizedlist>
</td>
@ -174,7 +174,7 @@
function normally — this is where extensions
come in.
</para>
<para> An <firstterm>extension</firstterm> adds capabilities to an API beyond those
<para>An <firstterm>extension</firstterm> 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 <firstterm>extension mechanism</firstterm>. 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. </para>
extensibility, the extensions themselves are never part of the core.</para>
</section>
<section>
<title>Relationship to OpenGL</title>
@ -211,15 +211,15 @@
needed to meet the goal of performing at real-time
speeds.
</para>
<para> Gaining vendor support is challenging because vendors are often in direct
<para>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. </para>
<para> The OpenGL extension mechanism was developed to solve these problems. The
and niche functionality to their users.</para>
<para>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. </para>
<para> OpenStack, while very different from OpenGL, shares many similar goals and faces
extension process and are now part of the core OpenGL API.</para>
<para>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. </para>
borrow heavily from OpenGL.</para>
</section>
<section>
<title>Extensions and Versions</title>
<para> Extensions are always interpreted in relation to a version of the core API. In
<para>Extensions are always interpreted in relation to a version of the core API. In
other words, from a client's perspective, an extension modifies <emphasis>a
particular version</emphasis> 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
<phrase security="draft">the chapter on "Extension Governance and Promotion"</phrase>,
for an extension at different versions. As explained in
<phrase security="draft">the chapter on "Extension Governance and Promotion"</phrase>,
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. </para>
may become a standard feature in a later version.</para>
<note>
<para>
As always, implementers are not required to
@ -272,19 +272,19 @@
core.
</para>
</note>
<para> Because several versions of the core API may be supported simultaneously, and
<para>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 <command>GET</command> on the
base URL (<code>/</code>) of the API endpoint returns information about what
versions are available. Similarly, issuing a <command>GET</command> on the API's extensions resource
(<code>/v1.1/extensions</code>) returns information about what extensions are
available. (See
<phrase security="draft">the chapter on "Extensions and ReST"</phrase>
available. (See
<phrase security="draft">the chapter on "Extensions and ReST"</phrase>
for details of such requests.) Note that,
since extensions modify a particular version of the API, the <code>extensions</code>
resource itself is always accessed at a particular version. </para>
<para> Backward-compatible changes in an API usually require a minor version bump. In an
resource itself is always accessed at a particular version.</para>
<para>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. </para>
features of a core API may be developed in a bottom-up fashion.</para>
<para>
That said, not all extensions are destined to be
promoted to the next API version. Core APIs always
@ -422,37 +422,37 @@
</section>
<section>
<title>Versioning Extensions</title>
<para> There is no explicit versioning mechanism for extensions. Nonetheless, there may
<para>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: <code>RAX-PIE2</code> updates <code>RAX-PIE</code>. </para>
<para> Extensions may have dependencies on other extensions. For example,
updates another: <code>RAX-PIE2</code> updates <code>RAX-PIE</code>.</para>
<para>Extensions may have dependencies on other extensions. For example,
<code>RAX-PIE2</code> may depend on <code>RAX-PIE</code> 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. </para>
particularly useful in cases where an existing extension has good client support.</para>
</section>
<section>
<title>Extensions and Pluggability</title>
<para> Core APIs abstract away vendor differences in order to provide a cross-platform
<para>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. </para>
<para> The core API contains only those capabilities which are applicable to all
of translating core API requests to it.</para>
<para>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. </para>
providing frontends to OpenStack plug-ins.</para>
<figure xml:id="core-extensions">
<title>Extensions and Pluggability</title>
<mediaobject>
@ -466,8 +466,4 @@
</figure>
</section>
</chapter>
</book>

View File

@ -28,7 +28,7 @@
</imageobject>
<imageobject role="html">
<imagedata fileref="../figures/Arrow_east.png"
/>
/>
</imageobject>
</inlinemediaobject>'>
]>
@ -69,7 +69,7 @@
<abstract>
<para>This document is intended for software developers interested in developing
applications using the OpenStack Compute Application Programming Interface
(<abbrev>API</abbrev>). </para>
(<abbrev>API</abbrev>).</para>
</abstract>
<cover>
<para>this is a placeholder for the front cover</para>
@ -327,16 +327,16 @@
Servers can occur programmatically via the OpenStack
Compute API.
</para>
<para> We welcome feedback, comments, and bug reports at <link
xlink:href="http://bugs.launchpad.net/nova">bugs.launchpad.net/nova</link>.
<para>We welcome feedback, comments, and bug reports at <link
xlink:href="http://bugs.launchpad.net/nova">bugs.launchpad.net/nova</link>.
</para>
<section>
<title>Intended Audience</title>
<para> This Guide is intended to assist software developers who want to develop
<para>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: </para>
also be familiar with:</para>
<itemizedlist spacing="compact">
<listitem>
<para>ReSTful web services</para>
@ -383,8 +383,8 @@
<para>You can download the most current version of this document from the OpenStack Docs
website at <link
xlink:href="http://docs.openstack.org">
http://docs.openstack.org</link>. </para>
<para> For more details about the Cloud Servers service that this API is based upon, please refer to <link
http://docs.openstack.org</link>.</para>
<para>For more details about the Cloud Servers service that this API is based upon, please refer to <link
xlink:href="http://www.rackspacecloud.com/cloud_hosting_products/servers"
>http://www.rackspacecloud.com/cloud_hosting_products/servers</link>. Related
documents, including an <link
@ -394,11 +394,10 @@
phone, chat, and email.</para>
</section>
</chapter>
<chapter>
<title>Concepts</title>
<para> To use the Cloud Servers API effectively, you should understand several key concepts: </para>
<para>To use the Cloud Servers API effectively, you should understand several key concepts:</para>
<section>
<title>Server</title>
<para>
@ -500,9 +499,9 @@
</chapter>
<chapter>
<title>General API Information</title>
<para> The Cloud Servers API is implemented using a ReSTful web service interface. Like
<para>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. </para>
authentication system that allows seamless access between products and services.</para>
<note>
<para>
All requests to authenticate and operate against Cloud
@ -512,15 +511,15 @@
</note>
<section>
<title>Authentication</title>
<para> Each ReST request against the Cloud Servers system requires the inclusion of a
<para>Each ReST request against the Cloud Servers system requires the inclusion of a
specific authorization token HTTP x-header, defined as <code>X-Auth-Token</code>.
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. </para>
<para> The Rackspace Cloud Authentication Service is a ReSTful web service. It is
the entry point to all Rackspace Cloud APIs. </para>
<para> To access the Authentication Service, you must know whether your account is
US-based or UK-based:
key.</para>
<para>The Rackspace Cloud Authentication Service is a ReSTful web service. It is
the entry point to all Rackspace Cloud APIs.</para>
<para>To access the Authentication Service, you must know whether your account is
US-based or UK-based:
</para>
<itemizedlist spacing="compact">
<listitem>
@ -537,14 +536,14 @@
<para>
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:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
If your account was
created via <link xlink:href="http://www.rackspacecloud.com">http://www.rackspacecloud.com</link>, it is a US-based account.
</para>
</para>
</listitem>
<listitem>
<para>
@ -594,7 +593,7 @@ X-Auth-Key: a86850deb2742ec3cb41518e26aa2d89
</simplesect>
<simplesect>
<title>Response</title>
<para> The Cloud Servers API may return any of the HTTP/1.1 response codes defined
<para>The Cloud Servers API may return any of the HTTP/1.1 response codes defined
by <link xlink:href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">
RFC-2616 Section 10</link>. If authentication is successful, an HTTP status
<returnvalue>204 (No Content)</returnvalue> is returned with three cloud
@ -607,7 +606,7 @@ X-Auth-Key: a86850deb2742ec3cb41518e26aa2d89
and must include the <code>X-Auth-Token</code> header as noted above. The URLs
specified in <code>X-Storage-Url</code> and <code>X-CDN-Management-Url</code>
are specific to the Cloud Files product and may be ignored for purposes of
interacting with Cloud Servers. </para>
interacting with Cloud Servers.</para>
<example>
<title>Authentication Response</title>
<literallayout class="monospaced">
@ -841,7 +840,7 @@ X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
<section>
<title>Efficient Polling with the
<parameter>Changes-Since</parameter> Parameter</title>
<para> The ReST API allows you to poll for the status of certain operations by
<para>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
<parameter>changes-since</parameter> 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?<parameter>changes-since</parameter>=1244012982
would list all servers that have changed since Wed, 03 Jun 2009 07:09:42 UTC. </para>
would list all servers that have changed since Wed, 03 Jun 2009 07:09:42 UTC.</para>
</section>
<?hard-pagebreak?>
<section>
@ -879,7 +878,7 @@ X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
<title>Rate Limits</title>
<para>
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/
<note>
<para>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. </para>
API service.</para>
</note>
</section>
<section>
<title>Faults</title>
<para> When an error occurs, the system will return an HTTP error response code denoting
<para>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. </para>
fault in the body of the response.</para>
<example>
<title>Fault Response: XML</title>
<programlisting language="xml">
@ -1185,11 +1184,11 @@ Host: servers.api.rackspacecloud.com/v1.0/
<xi:include href="samples/fault.json" parse="text"/>
</programlisting>
</example>
<para> The error code is returned in the body of the response for convenience. The
<para>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&mdash;for example, a stack trace&mdash;to
the end user. The details section is optional and may contain information&mdash;for example, a stack trace&mdash;to
assist in tracking down an error. The detail section may or may not be
appropriate for display to an end user. </para>
appropriate for display to an end user.</para>
<para>
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/
</simpara>
<para>This operation does not require a request body.</para>
<example>
<title>Addresses List Response: XML </title>
<title>Addresses List Response: XML</title>
<programlisting language="xml">
<xi:include href="samples/addresses.xml" parse="text"/>
</programlisting>
</example>
<example>
<title>Addresses List Response: JSON </title>
<title>Addresses List Response: JSON</title>
<programlisting language="javascript">
<xi:include href="samples/addresses.json" parse="text"/>
</programlisting>
@ -1889,7 +1888,7 @@ Host: servers.api.rackspacecloud.com/v1.0/
badRequest (<errorcode>400</errorcode>),
overLimit (<errorcode>413</errorcode>)
</para>
<para>This operation does not require a request body. </para>
<para>This operation does not require a request body.</para>
<example>
<title>Private Addresses List Response: XML</title>
<programlisting language="xml">
@ -2099,13 +2098,13 @@ Host: servers.api.rackspacecloud.com/v1.0/
equivalent of power cycling the server.
</para>
<example>
<title>Action Reboot: XML </title>
<title>Action Reboot: XML</title>
<programlisting language="xml">
<xi:include href="samples/reboot.xml" parse="text"/>
</programlisting>
</example>
<example>
<title>Action Reboot: JSON </title>
<title>Action Reboot: JSON</title>
<programlisting language="javascript">
<xi:include href="samples/reboot.json" parse="text"/>
</programlisting>
@ -2174,7 +2173,7 @@ Host: servers.api.rackspacecloud.com/v1.0/
addresses will remain the same.
</para>
<example>
<title>Action Rebuild: XML </title>
<title>Action Rebuild: XML</title>
<programlisting language="xml">
<xi:include href="samples/rebuild.xml" parse="text"/>
</programlisting>
@ -2466,7 +2465,7 @@ Host: servers.api.rackspacecloud.com/v1.0/
This operation does not require a request body.
</para>
<example>
<title>Flavors List Response: XML (detail) </title>
<title>Flavors List Response: XML (detail)</title>
<programlisting language="xml">
<xi:include href="samples/flavors.xml" parse="text"/>
</programlisting>
@ -2520,7 +2519,7 @@ Host: servers.api.rackspacecloud.com/v1.0/
</programlisting>
</example>
<example>
<title>Flavor Details Response: JSON </title>
<title>Flavor Details Response: JSON</title>
<programlisting language="javascript">
<xi:include href="samples/flavor.json" parse="text"/>
</programlisting>

View File

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?>
<addIp xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
configureServer="true" />
<addIp xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
configureServer="true" />

View File

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?>
<reboot xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
type="HARD"/>
<reboot xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
type="HARD"/>

View File

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?>
<rebuild xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
imageId="2"/>
<rebuild xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
imageId="2"/>

View File

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?>
<resize xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
flavorId="3"/>
<resize xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
flavorId="3"/>

View File

@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<server xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
id="1235" name="new-server-test"
imageId="1" flavorId="1"
hostId="e4d909c290d0fb1ca068ffaddf22cbd0"
progress="0" status="BUILD"
adminPass="GFf1j9aP">
id="1235" name="new-server-test"
imageId="1" flavorId="1"
hostId="e4d909c290d0fb1ca068ffaddf22cbd0"
progress="0" status="BUILD"
adminPass="GFf1j9aP">
<metadata>
<meta key="My Server Name">Apache1</meta>
</metadata>
@ -17,4 +17,4 @@
<ip addr="10.176.42.19"/>
</private>
</addresses>
</server>
</server>

View File

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?>
<shareIp xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
sharedIpGroupId="1234" configureServer="true" />
<shareIp xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
sharedIpGroupId="1234" configureServer="true" />

View File

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?>
<snapshot xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
imageName="Just in case"/>
<snapshot xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"
imageName="Just in case"/>

View File

@ -1899,7 +1899,7 @@ Host: servers.api.openstack.org/v2/
<td colspan="1"/>
<td colspan="3">
<code>BUILD</code> &ARROW;
<code>ERROR</code> (on error) </td>
<code>ERROR</code> (on error)</td>
</tr>
</tbody>
</informaltable>
@ -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. </td>
be unique.</td>
</tr>
<tr>
<td>
@ -2515,7 +2515,7 @@ Host: servers.api.openstack.org/v2/
<td colspan="3">
<code>ACTIVE</code> &ARROW;
<code>PASSWORD</code> &ARROW;
<code>ERROR</code> (on error) </td>
<code>ERROR</code> (on error)</td>
</tr>
<tr>
<td colspan="1"/>
@ -2523,7 +2523,7 @@ Host: servers.api.openstack.org/v2/
<code>ERROR</code> &ARROW;
<code>PASSWORD</code> &ARROW;
<code>ACTIVE</code> (password reset
after error) </td>
after error)</td>
</tr>
</tbody>
</informaltable>
@ -2620,7 +2620,7 @@ Host: servers.api.openstack.org/v2/
<code>ACTIVE</code> &ARROW;
<code>REBOOT</code> &ARROW;
<code>ACTIVE</code> (<property>soft
reboot</property>) </td>
reboot</property>)</td>
</tr>
<tr>
<td colspan="1"/>
@ -2628,7 +2628,7 @@ Host: servers.api.openstack.org/v2/
<code>ACTIVE</code> &ARROW;
<code>HARD_REBOOT</code> &ARROW;
<code>ACTIVE</code> (<property>hard
reboot</property>) </td>
reboot</property>)</td>
</tr>
</tbody>
</informaltable>
@ -2687,11 +2687,11 @@ Host: servers.api.openstack.org/v2/
<para>This operation does not return a response
body.</para>
<example>
<title>Action Reboot Request: XML </title>
<title>Action Reboot Request: XML</title>
<programlisting language="xml"><xi:include href="samples/reboot.xml" parse="text"/></programlisting>
</example>
<example>
<title>Action Reboot Request: JSON </title>
<title>Action Reboot Request: JSON</title>
<programlisting language="json"><xi:include href="samples/reboot.json" parse="text"/></programlisting>
</example>
</section>
@ -2748,7 +2748,7 @@ Host: servers.api.openstack.org/v2/
<td colspan="3">
<code>ACTIVE</code> &ARROW;
<code>REBUILD</code> &ARROW;
<code>ERROR</code> (on error) </td>
<code>ERROR</code> (on error)</td>
</tr>
</tbody>
</informaltable>
@ -2835,7 +2835,7 @@ Host: servers.api.openstack.org/v2/
</table>
</para>
<example>
<title>Action Rebuild Request: XML </title>
<title>Action Rebuild Request: XML</title>
<programlisting language="xml"><xi:include href="samples/rebuild_all.xml" parse="text"/></programlisting>
</example>
<?hard-pagebreak?>
@ -3027,7 +3027,7 @@ Host: servers.api.openstack.org/v2/
<td colspan="1"/>
<td colspan="3">
<code>VERIFY_RESIZE</code> &ARROW;
<code>ERROR</code> (on error) </td>
<code>ERROR</code> (on error)</td>
</tr>
</tbody>
</informaltable>
@ -3110,7 +3110,7 @@ Host: servers.api.openstack.org/v2/
<td colspan="3">
<code>VERIFY_RESIZE</code> &ARROW;
<code>REVERT_RESIZE</code> &ARROW;
<code>ERROR</code> (on error) </td>
<code>ERROR</code> (on error)</td>
</tr>
</tbody>
</informaltable>
@ -3199,7 +3199,7 @@ Host: servers.api.openstack.org/v2/
<td colspan="1"/>
<td colspan="3">
<code>SAVING</code> &ARROW;
<code>ERROR</code> (on error) </td>
<code>ERROR</code> (on error)</td>
</tr>
</tbody>
</informaltable>
@ -3380,7 +3380,7 @@ Host: servers.api.openstack.org/v2/
<para>This operation does not require a request
body.</para>
<example>
<title>Flavors List Response: XML (detail) </title>
<title>Flavors List Response: XML (detail)</title>
<programlisting language="xml"><xi:include href="samples/flavors.xml" parse="text"/></programlisting>
</example>
<example>
@ -3436,7 +3436,7 @@ Host: servers.api.openstack.org/v2/
</example>
<?hard-pagebreak?>
<example>
<title>Flavor Details Response: JSON </title>
<title>Flavor Details Response: JSON</title>
<programlisting language="json"><xi:include href="samples/flavor.json" parse="text"/></programlisting>
</example>
</section>
@ -3467,7 +3467,7 @@ Host: servers.api.openstack.org/v2/
<parameter>status</parameter>=<literal>imageStatus</literal>&amp;
<parameter>changes-since</parameter>=<literal>dateTime</literal>&amp;
<parameter>marker</parameter>=<literal>markerID</literal>&amp;<parameter>limit</parameter>=<literal>int</literal>&amp;
<parameter>type</parameter>=(<constant>BASE</constant>|<constant>SERVER</constant>) </td>
<parameter>type</parameter>=(<constant>BASE</constant>|<constant>SERVER</constant>)</td>
<td colspan="3">Lists IDs, names, and
links for all available images.</td>
</tr>
@ -3479,7 +3479,7 @@ Host: servers.api.openstack.org/v2/
<parameter>status</parameter>=<literal>imageStatus</literal>&amp;
<parameter>changes-since</parameter>=<literal>dateTime</literal>&amp;
<parameter>marker</parameter>=<literal>markerID</literal>&amp;<parameter>limit</parameter>=<literal>int</literal>&amp;
<parameter>type</parameter>=(<constant>BASE</constant>|<constant>SERVER</constant>) </td>
<parameter>type</parameter>=(<constant>BASE</constant>|<constant>SERVER</constant>)</td>
<td colspan="3">Lists all details for all
available images.</td>
</tr>
@ -3757,11 +3757,11 @@ Host: servers.api.openstack.org/v2/
<para>This operation does not require a request
body.</para>
<example>
<title>Metadata List Response: XML </title>
<title>Metadata List Response: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata.xml" parse="text"/></programlisting>
</example>
<example>
<title>Metadata List Response: JSON </title>
<title>Metadata List Response: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata.json" parse="text"/></programlisting>
</example>
</section>
@ -3855,20 +3855,20 @@ Host: servers.api.openstack.org/v2/
queried through the maxImageMeta absolute
limit.</para>
<example>
<title>Set Metadata Request: XML </title>
<title>Set Metadata Request: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata.xml" parse="text"/></programlisting>
</example>
<example>
<title>Set Metadata Request: JSON </title>
<title>Set Metadata Request: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata.json" parse="text"/></programlisting>
</example>
<?hard-pagebreak?>
<example>
<title>Set Metadata Response: XML </title>
<title>Set Metadata Response: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata.xml" parse="text"/></programlisting>
</example>
<example>
<title>Set Metadata Response: JSON </title>
<title>Set Metadata Response: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata.json" parse="text"/></programlisting>
</example>
</section>
@ -3962,20 +3962,20 @@ Host: servers.api.openstack.org/v2/
an image may be queried through the maxImageMeta
absolute limit.</para>
<example>
<title>Update Metadata Request: XML </title>
<title>Update Metadata Request: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata-update-req.xml" parse="text"/></programlisting>
</example>
<example>
<title>Update Metadata Request: JSON </title>
<title>Update Metadata Request: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata-update-req.json" parse="text"/></programlisting>
</example>
<?hard-pagebreak?>
<example>
<title>Update Metadata Response: XML </title>
<title>Update Metadata Response: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata-update-resp.xml" parse="text"/></programlisting>
</example>
<example>
<title>Update Metadata Response: JSON </title>
<title>Update Metadata Response: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata-update-resp.json" parse="text"/></programlisting>
</example>
</section>
@ -4028,11 +4028,11 @@ Host: servers.api.openstack.org/v2/
<para>This operation does not require a request
body.</para>
<example>
<title>Metadata Item Response: XML </title>
<title>Metadata Item Response: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata_item.xml" parse="text"/></programlisting>
</example>
<example>
<title>Metadata Item Response: JSON </title>
<title>Metadata Item Response: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata_item.json" parse="text"/></programlisting>
</example>
</section>
@ -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.</para>
<example>
<title>Set Metadata Item Request: XML </title>
<title>Set Metadata Item Request: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata_item.xml" parse="text"/></programlisting>
</example>
<example>
<title>Set Metadata Item Request: JSON </title>
<title>Set Metadata Item Request: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata_item.json" parse="text"/></programlisting>
</example>
<?hard-pagebreak?>
<example>
<title>Set Metadata Item Response: XML </title>
<title>Set Metadata Item Response: XML</title>
<programlisting language="xml"><xi:include href="samples/metadata_item.xml" parse="text"/></programlisting>
</example>
<example>
<title>Set Metadata Item Response: JSON </title>
<title>Set Metadata Item Response: JSON</title>
<programlisting language="json"><xi:include href="samples/metadata_item.json" parse="text"/></programlisting>
</example>
</section>

View File

@ -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"

View File

@ -11,10 +11,10 @@
<message>An internal error occured</message>
<details>Error details</details>
</fault>
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
<atom:link
<atom:link
rel="bookmark"
href="http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
</image>

View File

@ -7,11 +7,11 @@
<metadata>
<meta key="ImageVersion">1.5</meta>
<meta key="ImageType">Gold</meta>
<atom:link
<atom:link
rel="next"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f6f006e54/meta?marker=ImageType"/>
</metadata>
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f6f006e54"/>
</image>

View File

@ -4,7 +4,7 @@
xmlns:atom="http://www.w3.org/2005/Atom"
id="52415800-8b69-11e0-9b19-734f5736d2a2"
name="My Server Backup">
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
<atom:link

View File

@ -18,10 +18,10 @@
rel="bookmark"
href="http://servers.api.openstack.org/1234/servers/52415800-8b69-11e0-9b19-734f335aa7b3"/>
</server>
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
<atom:link
<atom:link
rel="bookmark"
href="http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
</image>

View File

@ -15,10 +15,10 @@
<image
id="52415800-8b69-11e0-9b19-734f5736d2a2"
name="My Server Backup">
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
<atom:link
<atom:link
rel="bookmark"
href="http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
</image>

View File

@ -2,7 +2,7 @@
<images xmlns="http://docs.openstack.org/compute/api/v1.1"
xmlns:atom="http://www.w3.org/2005/Atom">
<image id="52415800-8b69-11e0-9b19-734f5736d2a2" name="My Server Backup">
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
</image>

View File

@ -3,7 +3,7 @@
xmlns:atom="http://www.w3.org/2005/Atom">
<image id="52415800-8b69-11e0-9b19-734f6ff7c475"
name="Backup 2">
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f6ff7c475"/>
</image>

View File

@ -36,10 +36,10 @@
rel="bookmark"
href="http://servers.api.openstack.org/1234/servers/52415800-8b69-11e0-9b19-734f335aa7b3"/>
</server>
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
<atom:link
<atom:link
rel="bookmark"
href="http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
</image>

View File

@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<server xmlns="http://docs.openstack.org/compute/api/v1.1"
xmlns:atom="http://www.w3.org/2005/Atom"
id="52415800-8b69-11e0-9b19-734f565bc83b"
id="52415800-8b69-11e0-9b19-734f565bc83b"
tenant_id="1234" user_id="5678"
name="newName"
hostId="e4d909c290d0fb1ca068ffaddf22cbd0" progress="0"

View File

@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<rebuild
<rebuild
xmlns="http://docs.openstack.org/compute/api/v1.1"
name="newName"
imageRef="https://servers.api.rackspacecloud.com/v2/32278/images/52415800-8b69-11e0-9b19-734f6f006e54"

View File

@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<rebuild
<rebuild
xmlns="http://docs.openstack.org/compute/api/v1.1"
name="foobar"
imageRef="http://openstack.example.com/v1.1/32278/images/70a599e0-31e7-49b7-b260-868f441e862b"
@ -22,4 +22,4 @@
b25zLiINCg0KLVJpY2hhcmQgQmFjaA==
</file>
</personality>
</rebuild>
</rebuild>

View File

@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<server xmlns="http://docs.openstack.org/compute/api/v1.1" name="new-server-test"
<server xmlns="http://docs.openstack.org/compute/api/v1.1" name="new-server-test"
imageRef="http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f6f006e54"
flavorRef="http://servers.api.openstack.org/1234/flavors/52415800-8b69-11e0-9b19-734f1195ff37">
<metadata>

View File

@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<server xmlns="http://docs.openstack.org/compute/api/v1.1"
xmlns:atom="http://www.w3.org/2005/Atom"
id="52415800-8b69-11e0-9b19-734f565bc83b"
id="52415800-8b69-11e0-9b19-734f565bc83b"
tenant_id="1234" user_id="5678"
name="new-server-test"
hostId="e4d909c290d0fb1ca068ffaddf22cbd0" progress="0"

View File

@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<server xmlns="http://docs.openstack.org/compute/api/v1.1"
xmlns:atom="http://www.w3.org/2005/Atom"
id="52415800-8b69-11e0-9b19-734f565bc83b"
id="52415800-8b69-11e0-9b19-734f565bc83b"
tenant_id="1234" user_id="5678"
name="new-server-test"
hostId="e4d909c290d0fb1ca068ffaddf22cbd0" progress="0"

View File

@ -3,7 +3,7 @@
xmlns:atom="http://www.w3.org/2005/Atom">
<server id="52415800-8b69-11e0-9b19-734f6af67565"
tenant_id="1234" user_id="5678"
name="sample-server" status="BUILD"
name="sample-server" status="BUILD"
progress="60" hostId="e4d909c290d0fb1ca068ffaddf22cbd0"
updated="2010-10-10T12:00:00Z"
created="2010-08-10T12:00:00Z"
@ -63,10 +63,10 @@
<image
id="52415800-8b69-11e0-9b19-734f5736d2a2"
name="My Server Backup">
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
<atom:link
<atom:link
rel="bookmark"
href="http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
</image>

View File

@ -3,7 +3,7 @@
xmlns:atom="http://www.w3.org/2005/Atom">
<server id="52415800-8b69-11e0-9b19-734f6af67565"
tenant_id="1234" user_id="5678"
name="sample-server" status="BUILD"
name="sample-server" status="BUILD"
progress="60" hostId="e4d909c290d0fb1ca068ffaddf22cbd0"
updated="2010-10-10T12:00:00Z"
created="2010-08-10T12:00:00Z"
@ -59,10 +59,10 @@
accessIPv6="::babe:67.23.10.133"
>
<image id="52415800-8b69-11e0-9b19-734f5736d2a2">
<atom:link
<atom:link
rel="self"
href="http://servers.api.openstack.org/v2/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
<atom:link
<atom:link
rel="bookmark"
href="http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f5736d2a2"/>
</image>

View File

@ -5,36 +5,36 @@
<media-type base="application/xml" type="application/vnd.vendor.service-v1.0+xml"/>
<media-type base="application/json" type="application/vnd.vendor.service-v1.0+json"/>
</media-types>
<atom:link rel="self" href="http://service.api.vendor.com/v1.0/"/>
</version>
<version id="v2" status="CURRENT" updated="2010-12-12T18:30:02.25Z">
<media-types>
<media-type base="application/xml" type="application/vnd.vendor.service-v2+xml"/>
<media-type base="application/json" type="application/vnd.vendor.service-v2+json"/>
</media-types>
<atom:link rel="describedby" href="http://service.api.vendor.com/v2/"/>
</version>
<version id="v1.2" status="BETA" updated="2011-01-13T09:25:02Z">
<media-types>
<media-type base="application/xml" type="application/vnd.vendor.service-v1.2+xml"/>
<media-type base="application/json" type="application/vnd.vendor.service-v1.2+json"/>
<media-type base="application/atom" type="application/vnd.vendor.service-v1.2+atom"/>
</media-types>
<atom:link rel="self" href="http://service.api.vendor.com/v1.2/"/>
</version>
<version id="v2" status="ALPHA" updated="2011-01-15T10:10:10Z">
<media-types>
<media-type base="application/xml" type="application/vnd.vendor.service-v2+xml"/>
<media-type base="application/json" type="application/vnd.vendor.service-v2+json"/>
<media-type base="application/atom" type="application/vnd.vendor.service-v2+atom"/>
</media-types>
<atom:link rel="self" href="http://service.api.vendor.com/v2/"/>
</version>
</versions>

View File

@ -5,7 +5,7 @@
<!ENTITY mdash "&#x2014;">
<!ENTITY hellip "&#x2026;">
<!ENTITY plusmn "&#xB1;">
<!-- Useful for describing APIs -->
<!ENTITY GET '<command xmlns="http://docbook.org/ns/docbook">GET</command>'>
<!ENTITY PUT '<command xmlns="http://docbook.org/ns/docbook">PUT</command>'>
@ -23,19 +23,19 @@
<?dbhtml stop-chunking?>
<title>Concepts</title>
<para>To use the OpenStack Compute API effectively, you should
understand several key concepts: </para>
understand several key concepts:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Server</emphasis></para>
<para>A virtual machine (VM) instance in the compute
system. Flavor and image are requisite elements when
creating a server. </para>
creating a server.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Flavor</emphasis></para>
<para>An available hardware configuration for a server.
Each flavor has a unique combination of disk space,
memory capacity and priority for CPU time. </para>
memory capacity and priority for CPU time.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Image</emphasis></para>
@ -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. </para>
particular server configuration frequently.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Reboot</emphasis></para>
@ -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. </para>
halted/stopped.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Rebuild</emphasis></para>
<para>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. </para>
addresses remain the same.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Resize</emphasis></para>
@ -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. </para>
are automatically confirmed after 24 hours if you do not
confirm or revert them.</para>
</listitem>
</itemizedlist>
</section>