Reorganize layout
Update to clouddocs-maven-plugin 2.0.2 Also created parent pom.xml file and updated pom.xml files in v1.0 and v2 dirs to point to parent Changed directory structure slightly to mimic other API dir structures. Added xml:id to sections and chapters in the v1.0 book and the incubation document. Moved shared graphics to figures directory in root directory. Update doc-test.conf for the changes Change-Id: Iae6dddbe39a536c5c71be5919b28f69e588fea43
This commit is contained in:
Andreas Jaeger
Diane Fleming
parent
0d3206c3fb
commit
cc06396a16
@ -3,10 +3,10 @@ repo_name = compute-api
|
|||||||
api_site = True
|
api_site = True
|
||||||
|
|
||||||
ignore_dir=incubation
|
ignore_dir=incubation
|
||||||
ignore_dir=openstack-compute-api-1.0
|
ignore_dir=v1.0
|
||||||
|
|
||||||
# These three options need to come together:
|
# These three options need to come together:
|
||||||
book = openstack-compute-api-2
|
book = v2
|
||||||
target_dir = target/docbkx/webhelp/api/openstack-compute/2
|
target_dir = target/docbkx/webhelp/api/openstack-compute/2
|
||||||
# Published at http://docs.openstack.org/api/openstack-compute/2/
|
# Published at http://docs.openstack.org/api/openstack-compute/2/
|
||||||
publish_dir = api/openstack-compute/2/
|
publish_dir = api/openstack-compute/2/
|
||||||
|
|||||||
|
Before Width: | Height: | Size: 433 B After Width: | Height: | Size: 433 B |
|
Before Width: | Height: | Size: 2.1 KiB After Width: | Height: | Size: 2.1 KiB |
|
Before Width: | Height: | Size: 651 B After Width: | Height: | Size: 651 B |
|
Before Width: | Height: | Size: 2.1 KiB After Width: | Height: | Size: 2.1 KiB |
@ -1,4 +1,12 @@
|
|||||||
<?xml version="1.0" encoding="UTF-8"?><book xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:svg="http://www.w3.org/2000/svg" xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:db="http://docbook.org/ns/docbook" version="5.0" status="draft">
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<book xmlns="http://docbook.org/ns/docbook"
|
||||||
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
|
xmlns:svg="http://www.w3.org/2000/svg"
|
||||||
|
xmlns:m="http://www.w3.org/1998/Math/MathML"
|
||||||
|
xmlns:html="http://www.w3.org/1999/xhtml"
|
||||||
|
xmlns:db="http://docbook.org/ns/docbook" version="5.0"
|
||||||
|
status="draft" xml:id="apix-proposal">
|
||||||
<title>OpenStack API Extensions</title>
|
<title>OpenStack API Extensions</title>
|
||||||
<subtitle>An Overview</subtitle>
|
<subtitle>An Overview</subtitle>
|
||||||
<info>
|
<info>
|
||||||
@ -10,156 +18,164 @@
|
|||||||
<pubdate>2011-06-10</pubdate>
|
<pubdate>2011-06-10</pubdate>
|
||||||
<legalnotice role="apache2">
|
<legalnotice role="apache2">
|
||||||
<annotation>
|
<annotation>
|
||||||
<remark>Copyright details are filled in by the template.</remark>
|
<remark>Copyright details are filled in by the
|
||||||
|
template.</remark>
|
||||||
</annotation>
|
</annotation>
|
||||||
</legalnotice>
|
</legalnotice>
|
||||||
<abstract>
|
<abstract>
|
||||||
<para>
|
<para>This document provides an overview of the OpenStack
|
||||||
This document provides an overview of the OpenStack API extension
|
API extension mechanism.</para>
|
||||||
mechanism.
|
|
||||||
</para>
|
|
||||||
</abstract>
|
</abstract>
|
||||||
</info>
|
</info>
|
||||||
<chapter version="5.0" xml:base="chapters/overview.xml">
|
<chapter version="5.0" xml:base="chapters/overview.xml"
|
||||||
<title>Overview</title>
|
xml:id="overview">
|
||||||
<para>
|
<title>Overview</title>
|
||||||
The OpenStack extension mechanism makes it possible to add
|
<para>The OpenStack extension mechanism makes it possible to
|
||||||
functionality to OpenStack APIs in a manner that ensures
|
add functionality to OpenStack APIs in a manner that
|
||||||
compatibility with existing clients. This capability
|
ensures compatibility with existing clients. This
|
||||||
allows OpenStack operators and vendors to provide
|
capability allows OpenStack operators and vendors to
|
||||||
innovative functionality to their clients and provides a
|
provide innovative functionality to their clients and
|
||||||
means by which new features may be considered in upcoming
|
provides a means by which new features may be considered
|
||||||
versions of OpenStack APIs.
|
in upcoming versions of OpenStack APIs.</para>
|
||||||
</para>
|
<para>This document describes the extension mechanism in
|
||||||
<para>
|
detail. It provides guidance to API implementors and
|
||||||
This document describes the extension mechanism in detail.
|
clients on developing and consuming API extensions, it
|
||||||
It provides guidance to API implementors and clients on
|
describes the rules by which extensions are governed, and
|
||||||
developing and consuming API extensions, it describes the
|
it describes the process used to promote API extensions to
|
||||||
rules by which extensions are governed, and it describes
|
new features.</para>
|
||||||
the process used to promote API extensions to new features.
|
<warning security="draft">
|
||||||
</para>
|
<para>Please note that this document is a <emphasis
|
||||||
<warning security="draft">
|
role="strong">draft</emphasis>. It is intended to
|
||||||
<para>Please note that this document is a <emphasis role="strong">draft</emphasis>. It
|
give developers an opportunity to provide feedback. If
|
||||||
is intended to give developers an opportunity to provide feedback. If you begin
|
you begin implementing against this early access
|
||||||
implementing against this early access specification, please recognize that it is
|
specification, please recognize that it is still
|
||||||
still subject to change. Comments, feedback, and bug reports are always welcomed;
|
subject to change. Comments, feedback, and bug reports
|
||||||
please submit these in the webhelp discussion forum at: <link xlink:href="http://docs.openstack.org/">http://docs.openstack.org/</link>.</para>
|
are always welcomed; please submit these in the
|
||||||
</warning>
|
webhelp discussion forum at: <link
|
||||||
<section>
|
xlink:href="http://docs.openstack.org/"
|
||||||
<title>Intended Audience</title>
|
>http://docs.openstack.org/</link>.</para>
|
||||||
<para>This document is intended for software developers who wish either to implement or
|
</warning>
|
||||||
to consume an extendable OpenStack API. It assumes that the reader has a general
|
<section xml:id="audience">
|
||||||
understanding of:</para>
|
<title>Intended Audience</title>
|
||||||
<itemizedlist spacing="compact">
|
<para>This document is intended for software developers
|
||||||
<listitem>
|
who wish either to implement or to consume an
|
||||||
<para>ReSTful web services</para>
|
extensible OpenStack API. It assumes that the reader
|
||||||
</listitem>
|
has a general understanding of:</para>
|
||||||
<listitem>
|
<itemizedlist spacing="compact">
|
||||||
<para>HTTP/1.1</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>JSON and/or XML data serialization formats</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>At least one OpenStack API: Compute,
|
|
||||||
Object Storage, etc.</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section>
|
|
||||||
<title>Organization of this Document</title>
|
|
||||||
<variablelist spacing="normal">
|
|
||||||
<?dbfo list-presentation="blocks"?>
|
|
||||||
<varlistentry>
|
|
||||||
<term><xref linkend="Background"/></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>ReSTful web services</para>
|
||||||
Provides background information on
|
|
||||||
OpenStack extensions and the OpenStack
|
|
||||||
extension mechanism.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><phrase security="draft">Chapter 3, <firstterm>Extensions and ReST</firstterm></phrase></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>HTTP/1.1</para>
|
||||||
Describes the specifics of implementing
|
|
||||||
and consuming extensions in ReST APIs.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><phrase security="draft">Chapter 4, <firstterm>Extension Governance and Promotion</firstterm></phrase></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>JSON and/or XML data serialization
|
||||||
Describes API governance and the process
|
formats</para>
|
||||||
by which extensions can be promoted to new
|
|
||||||
features in future revisions of an API.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><phrase security="draft">Chapter 5, <firstterm>Summary</firstterm></phrase></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Briefly summarizes the benefits of the extension mechanism and
|
<para>At least one OpenStack API: Compute, Object
|
||||||
provides a brief overview of how extensions are used.</para>
|
Storage, etc.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</itemizedlist>
|
||||||
</variablelist>
|
</section>
|
||||||
</section>
|
<section xml:id="organization">
|
||||||
<section>
|
<title>Organization of this Document</title>
|
||||||
<title>Document Change History</title>
|
<variablelist spacing="normal">
|
||||||
<informaltable rules="all">
|
<?dbfo list-presentation="blocks"?>
|
||||||
<thead>
|
<varlistentry>
|
||||||
<tr>
|
<term><xref linkend="Background"/></term>
|
||||||
<td align="center" colspan="1">Revision Date</td>
|
<listitem>
|
||||||
<td align="center" colspan="4">Summary of Changes</td>
|
<para>Provides background information on
|
||||||
</tr>
|
OpenStack extensions and the OpenStack
|
||||||
</thead>
|
extension mechanism.</para>
|
||||||
<tbody>
|
</listitem>
|
||||||
<tr>
|
</varlistentry>
|
||||||
<td colspan="1" align="center">June 10, 2011</td>
|
<varlistentry>
|
||||||
<td colspan="4">
|
<term><phrase security="draft">Chapter 3,
|
||||||
<itemizedlist spacing="compact">
|
<firstterm>Extensions and
|
||||||
<listitem>
|
ReST</firstterm></phrase></term>
|
||||||
<para>Initial draft.</para>
|
<listitem>
|
||||||
</listitem>
|
<para>Describes the specifics of implementing
|
||||||
</itemizedlist>
|
and consuming extensions in ReST APIs.
|
||||||
</td>
|
</para>
|
||||||
</tr>
|
</listitem>
|
||||||
</tbody>
|
</varlistentry>
|
||||||
</informaltable>
|
<varlistentry>
|
||||||
</section>
|
<term><phrase security="draft">Chapter 4,
|
||||||
</chapter>
|
<firstterm>Extension Governance and
|
||||||
<chapter xml:id="Background" version="5.0" xml:base="chapters/background.xml">
|
Promotion</firstterm></phrase></term>
|
||||||
|
<listitem>
|
||||||
|
<para>Describes API governance and the process
|
||||||
|
by which extensions can be promoted to new
|
||||||
|
features in future revisions of an
|
||||||
|
API.</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<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>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</section>
|
||||||
|
<section xml:id="history">
|
||||||
|
<title>Document Change History</title>
|
||||||
|
<informaltable rules="all">
|
||||||
|
<thead>
|
||||||
|
<tr>
|
||||||
|
<td align="center" colspan="1">Revision
|
||||||
|
Date</td>
|
||||||
|
<td align="center" colspan="4">Summary of
|
||||||
|
Changes</td>
|
||||||
|
</tr>
|
||||||
|
</thead>
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<td colspan="1" align="center">June 10,
|
||||||
|
2011</td>
|
||||||
|
<td colspan="4">
|
||||||
|
<itemizedlist spacing="compact">
|
||||||
|
<listitem>
|
||||||
|
<para>Initial draft.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</informaltable>
|
||||||
|
</section>
|
||||||
|
</chapter>
|
||||||
|
<chapter xml:id="Background" version="5.0"
|
||||||
|
xml:base="chapters/background.xml">
|
||||||
<title>Background</title>
|
<title>Background</title>
|
||||||
<para>
|
<para>This chapter provides background information on
|
||||||
This chapter provides background information on OpenStack
|
OpenStack extensions and the OpenStack extension
|
||||||
extensions and the OpenStack extension mechanism. It
|
mechanism. It describes what extensions are, how the
|
||||||
describes what extensions are, how the extension mechanism
|
extension mechanism in OpenStack is related to the OpenGL
|
||||||
in OpenStack is related to the OpenGL extension mechanism,
|
extension mechanism, the differences between extensions
|
||||||
the differences between extensions and versions, the
|
and versions, the concept of versioning extensions, and
|
||||||
concept of versioning extensions, and why extensions are
|
why extensions are vital when defining a pluggable
|
||||||
vital when defining a pluggable architecture.
|
architecture.</para>
|
||||||
</para>
|
<section xml:id="what-are-extensions">
|
||||||
<section>
|
|
||||||
<title>What are Extensions?</title>
|
<title>What are Extensions?</title>
|
||||||
<para>
|
<para>OpenStack APIs are defined strictly in two forms: a
|
||||||
OpenStack APIs are defined strictly in two forms: a
|
|
||||||
human-readable specification (usually in the form of a
|
human-readable specification (usually in the form of a
|
||||||
developer's guide) and a machine-processable
|
developer's guide) and a machine-processable WADL.
|
||||||
WADL. These specifications define the core actions,
|
These specifications define the core actions,
|
||||||
capabilities, and media-types of the API. A client can
|
capabilities, and media-types of the API. A client can
|
||||||
always depend on the availability of this
|
always depend on the availability of this
|
||||||
<firstterm>core API</firstterm> and implementers are
|
<firstterm>core API</firstterm> and implementers
|
||||||
always required to support it in its entirety. Requiring strict adherence to the
|
are always required to support it in its entirety.
|
||||||
core API allows clients to rely upon a minimal level
|
Requiring strict adherence to the core API allows
|
||||||
of functionality when interacting with multiple
|
clients to rely upon a minimal level of functionality
|
||||||
implementations of the same API.
|
when interacting with multiple implementations of the
|
||||||
</para>
|
same API.</para>
|
||||||
<para>
|
<para>Note that it is quite possible that distinct
|
||||||
Note that it is quite possible that distinct
|
|
||||||
implementations of an OpenStack API exist. First
|
implementations of an OpenStack API exist. First
|
||||||
because API specifications are released under a free
|
because API specifications are released under a free
|
||||||
license, so anyone may use them to implement a core
|
license, so anyone may use them to implement a core
|
||||||
@ -171,296 +187,331 @@
|
|||||||
implement new features or add new capabilities, but
|
implement new features or add new capabilities, but
|
||||||
only if it made the changes in a manner that ensures
|
only if it made the changes in a manner that ensures
|
||||||
that a client expecting a core API would continue to
|
that a client expecting a core API would continue to
|
||||||
function normally — this is where extensions
|
function normally — this is where extensions come
|
||||||
come in.
|
in.</para>
|
||||||
</para>
|
<para>An <firstterm>extension</firstterm> adds
|
||||||
<para>An <firstterm>extension</firstterm> adds capabilities to an API beyond those
|
capabilities to an API beyond those defined in the
|
||||||
defined in the core. The introduction of new features, MIME types, actions, states,
|
core. The introduction of new features, MIME types,
|
||||||
headers, parameters, and resources can all be accomplished by means of extensions to
|
actions, states, headers, parameters, and resources
|
||||||
the core API. In order for extensions to work, the core API must be written in such
|
can all be accomplished by means of extensions to the
|
||||||
a manner that it allows for extensibility. Additionally, care should be taken to
|
core API. In order for extensions to work, the core
|
||||||
ensure that extensions defined by different implementers don't clash with one
|
API must be written in such a manner that it allows
|
||||||
another, that clients can detect the presence of extensions via a standard method,
|
for extensibility. Additionally, care should be taken
|
||||||
and that there is a clear promotion path at the end of which an extension may become
|
to ensure that extensions defined by different
|
||||||
part of a future version of the core API. These actions, rules, and processes
|
implementers don't clash with one another, that
|
||||||
together form the <firstterm>extension mechanism</firstterm>. It is important that
|
clients can detect the presence of extensions via a
|
||||||
core APIs adhere to this mechanism in order to ensure compatibility as new
|
standard method, and that there is a clear promotion
|
||||||
extensions are defined. Note also that while a core API may be written to allow for
|
path at the end of which an extension may become part
|
||||||
extensibility, the extensions themselves are never part of the core.</para>
|
of a future version of the core API. These actions,
|
||||||
|
rules, and processes 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>
|
||||||
</section>
|
</section>
|
||||||
<section>
|
<section xml:id="opengl">
|
||||||
<title>Relationship to OpenGL</title>
|
<title>Relationship to OpenGL</title>
|
||||||
<para>
|
<para>In the 1990s, OpenGL was developed as a portable
|
||||||
In the 1990s, OpenGL was developed as a portable open
|
open graphics library standard. The goal was to
|
||||||
graphics library standard. The goal was to provide a
|
provide a cross-platform library that could enable
|
||||||
cross-platform library that could enable developers to
|
developers to produce 3D graphics at real time speeds
|
||||||
produce 3D graphics at real time speeds (30-120 frames
|
(30-120 frames per second). There were several major
|
||||||
per second). There were several major challenges to
|
challenges to meeting this goal. In order to be
|
||||||
meeting this goal. In order to be considered an open
|
considered an open standard, control needed to shift
|
||||||
standard, control needed to shift from Silicon
|
from Silicon Graphics (SGI), who originally developed
|
||||||
Graphics (SGI), who originally developed OpenGL, to an
|
OpenGL, to an independent Architecture Review Board
|
||||||
independent Architecture Review Board (ARB) who would
|
(ARB) who would be responsible for approving
|
||||||
be responsible for approving specification changes,
|
specification changes, marking new releases, and
|
||||||
marking new releases, and ensuring conformance
|
ensuring conformance testing. Additionally, the
|
||||||
testing. Additionally, the graphics library itself
|
graphics library itself would need to be designed in a
|
||||||
would need to be designed in a manner that would allow
|
manner that would allow the establishment of a stable
|
||||||
the establishment of a stable and portable platform
|
and portable platform for developers. Finally, the
|
||||||
for developers. Finally, the library would need to
|
library would need to garner the support of graphics
|
||||||
garner the support of graphics hardware vendors as
|
hardware vendors as they would be providing the
|
||||||
they would be providing the hardware acceleration
|
hardware acceleration needed to meet the goal of
|
||||||
needed to meet the goal of performing at real-time
|
performing at real-time speeds.</para>
|
||||||
speeds.
|
<para>Gaining vendor support is challenging because
|
||||||
</para>
|
vendors are often in direct competition with one
|
||||||
<para>Gaining vendor support is challenging because vendors are often in direct
|
another. They differentiate themselves by creating
|
||||||
competition with one another. They differentiate themselves by creating innovative
|
innovative new features and by providing niche
|
||||||
new features and by providing niche functionality to their users. Thus, OpenGL was
|
functionality to their users. Thus, OpenGL was faced
|
||||||
faced with two competing requirements. On the one hand, it needed to abstract away
|
with two competing requirements. On the one hand, it
|
||||||
vendor differences in order to provide a stable cross-platform environment to
|
needed to abstract away vendor differences in order to
|
||||||
developers. On the other hand, in order to garner vendor support, it needed a method
|
provide a stable cross-platform environment to
|
||||||
by which vendors could differentiate themselves and provide innovative new features
|
developers. On the other hand, in order to garner
|
||||||
and niche functionality to their users.</para>
|
vendor support, it needed a method by which vendors
|
||||||
<para>The OpenGL extension mechanism was developed to solve these problems. The
|
could differentiate themselves and provide innovative
|
||||||
extension mechanism achieved balance between the two requirements by maintaining the
|
new features and niche functionality to their
|
||||||
core specification under the direction of the Architecture Review Board while
|
users.</para>
|
||||||
allowing vendors to define extensions to the core OpenGL specification. The core
|
<para>The OpenGL extension mechanism was developed to
|
||||||
specification remained uncluttered and presented a unified view of common
|
solve these problems. The extension mechanism achieved
|
||||||
functionality. Because extensions were detectable at run time, developers could
|
balance between the two requirements by maintaining
|
||||||
write portable applications that could adapt to the hardware on which they were
|
the core specification under the direction of the
|
||||||
running. This method of allowing for an extensible API has proven to be a very
|
Architecture Review Board while allowing vendors to
|
||||||
successful strategy. More than 500 extensions have been defined in OpenGL's lifetime
|
define extensions to the core OpenGL specification.
|
||||||
and many vendors, including NVidia, ATI, Apple, IBM, and Intel, have participated in
|
The core specification remained uncluttered and
|
||||||
the process by developing their own custom extensions. Additionally, many key
|
presented a unified view of common functionality.
|
||||||
innovations (such as vertex and fragment shaders) have been developed via the
|
Because extensions were detectable at run time,
|
||||||
extension process and are now part of the core OpenGL API.</para>
|
developers could write portable applications that
|
||||||
<para>OpenStack, while very different from OpenGL, shares many similar goals and faces
|
could adapt to the hardware on which they were
|
||||||
many of the same challenges. OpenStack APIs are designed to be open API standards.
|
running. This method of allowing for an extensible API
|
||||||
An important goal is to provide developers with a ubiquitous, stable, any-scale
|
has proven to be a very successful strategy. More than
|
||||||
cloud development platform that abstracts away many of the differences between
|
500 extensions have been defined in OpenGL's lifetime
|
||||||
hosting providers and their underlying infrastructure (hypervisors, load balancers,
|
and many vendors, including NVidia, ATI, Apple, IBM,
|
||||||
etc.). A Policy Review Board, similar to OpenGL's Architecture Review Board, is
|
and Intel, have participated in the process by
|
||||||
responsible for directing development of these APIs in a manner that ensures these
|
developing their own custom extensions. Additionally,
|
||||||
goals are met. As with OpenGL, OpenStack requires support from vendors (and cloud
|
many key innovations (such as vertex and fragment
|
||||||
providers) in order to be successful. As a result, OpenStack APIs also aim to
|
shaders) have been developed via the extension process
|
||||||
provide vendors with a platform which allows them to differentiate themselves by
|
and are now part of the core OpenGL API.</para>
|
||||||
providing innovative new features and niche functionality to their users. Because of
|
<para>OpenStack, while very different from OpenGL, shares
|
||||||
these similarities, the OpenStack extension mechanism described in this document is
|
many similar goals and faces many of the same
|
||||||
modeled after the OpenGL extension mechanism. The methods by which extensions are
|
challenges. OpenStack APIs are designed to be open API
|
||||||
defined vary drastically, of course, since the nature of the APIs is very different
|
standards. An important goal is to provide developers
|
||||||
(C versus ReST); however, the manner in which extensions are documented, the way in
|
with a ubiquitous, stable, any-scale cloud development
|
||||||
which vendors are attributed, and the promotion path that an extension follows, all
|
platform that abstracts away many of the differences
|
||||||
borrow heavily from OpenGL.</para>
|
between hosting providers and their underlying
|
||||||
|
infrastructure (hypervisors, load balancers, etc.). A
|
||||||
|
Policy Review Board, similar to OpenGL's Architecture
|
||||||
|
Review Board, is responsible for directing development
|
||||||
|
of these APIs in a manner that ensures these goals are
|
||||||
|
met. As with OpenGL, OpenStack requires support from
|
||||||
|
vendors (and cloud providers) in order to be
|
||||||
|
successful. As a result, OpenStack APIs also aim to
|
||||||
|
provide vendors with a platform which allows them to
|
||||||
|
differentiate themselves by providing innovative new
|
||||||
|
features and niche functionality to their users.
|
||||||
|
Because of these similarities, the OpenStack extension
|
||||||
|
mechanism described in this document is modeled after
|
||||||
|
the OpenGL extension mechanism. The methods by which
|
||||||
|
extensions are 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>
|
||||||
</section>
|
</section>
|
||||||
<section>
|
<section xml:id="extensions_and_versions">
|
||||||
<title>Extensions and Versions</title>
|
<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
|
||||||
other words, from a client's perspective, an extension modifies <emphasis>a
|
version of the core API. In other words, from a
|
||||||
particular version</emphasis> of the core API in some way. In reality, an
|
client's perspective, an extension modifies
|
||||||
extension may be applicable to several versions of an API at once. For example, a
|
<emphasis>a particular version</emphasis> of the
|
||||||
particular extension may continue to be available as a core API moves from one
|
core API in some way. In reality, an extension may be
|
||||||
version to another. In fact, different implementations may decide to include support
|
applicable to several versions of an API at once. For
|
||||||
for an extension at different versions. As explained in
|
example, a particular extension may continue to be
|
||||||
<phrase security="draft">the chapter on "Extension Governance and Promotion"</phrase>,
|
available as a core API moves from one version to
|
||||||
when an extension is defined, the minimal version of the core API that is required
|
another. In fact, different implementations may decide
|
||||||
to run the extension is specified; implementers are free to support the extension in
|
to include support for an extension at different
|
||||||
that version or in a later version of the core. Note, however, that because the
|
versions. As explained in <phrase security="draft">the
|
||||||
extension mechanism allows for promotion, an extension in one version of a core API
|
chapter on "Extension Governance and
|
||||||
may become a standard feature in a later version.</para>
|
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>
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>As always, implementers are not required to
|
||||||
As always, implementers are not required to
|
|
||||||
support an extension unless it is promoted to the
|
support an extension unless it is promoted to the
|
||||||
core.
|
core.</para>
|
||||||
</para>
|
|
||||||
</note>
|
</note>
|
||||||
<para>Because several versions of the core API may be supported simultaneously, and
|
<para>Because several versions of the core API may be
|
||||||
because each version may offer support for a different set of extensions, clients
|
supported simultaneously, and because each version may
|
||||||
must be able to detect what versions and extensions are available in a particular
|
offer support for a different set of extensions,
|
||||||
deployment. Thus, both extensions and versions are queryable. Issuing a <command>GET</command> on the
|
clients must be able to detect what versions and
|
||||||
base URL (<code>/</code>) of the API endpoint returns information about what
|
extensions are available in a particular deployment.
|
||||||
versions are available. Similarly, issuing a <command>GET</command> on the API's extensions resource
|
Thus, both extensions and versions are query-able.
|
||||||
(<code>/v1.1/extensions</code>) returns information about what extensions are
|
Issuing a <command>GET</command> on the base URL
|
||||||
available. (See
|
(<code>/</code>) of the API endpoint returns
|
||||||
<phrase security="draft">the chapter on "Extensions and ReST"</phrase>
|
information about what versions are available.
|
||||||
for details of such requests.) Note that,
|
Similarly, issuing a <command>GET</command> on the
|
||||||
since extensions modify a particular version of the API, the <code>extensions</code>
|
API's extensions resource
|
||||||
resource itself is always accessed at a particular version.</para>
|
(<code>/v1.1/extensions</code>) returns
|
||||||
<para>Backward-compatible changes in an API usually require a minor version bump. In an
|
information about what extensions are available. (See
|
||||||
extensible API, however, these changes can be brought in as extensions. The net
|
<phrase security="draft">the chapter on
|
||||||
effect is that versions change infrequently and thus provide a stable platform on
|
"Extensions and ReST"</phrase> for details of such
|
||||||
which to develop. The Policy Review Board (PRB), with the help of project team
|
requests.) Note that, since extensions modify a
|
||||||
leaders, is responsible for ensuring that this stability is maintained by closely
|
particular version of the API, the
|
||||||
guarding core API versions. Extensions, however, can be developed without the
|
<code>extensions</code> resource itself is always
|
||||||
consent or approval of the PRB. They can be developed in a completely decentralized
|
accessed at a particular version.</para>
|
||||||
manner both by individual OpenStack developers and by commercial vendors. Because
|
<para>Backward-compatible changes in an API usually
|
||||||
extensions can be promoted to standard features, the development of new versions can
|
require a minor version bump. In an extensible API,
|
||||||
be influenced significantly by individual developers and the OpenStack client
|
however, these changes can be brought in as
|
||||||
community and is therefore not strictly defined by the PRB. In other words, new
|
extensions. The net effect is that versions change
|
||||||
features of a core API may be developed in a bottom-up fashion.</para>
|
infrequently and thus provide a stable platform on
|
||||||
<para>
|
which to develop. The Policy Review Board (PRB), with
|
||||||
That said, not all extensions are destined to be
|
the help of project team leaders, is responsible for
|
||||||
|
ensuring that this stability is maintained by closely
|
||||||
|
guarding core API versions. Extensions, however, can
|
||||||
|
be developed without the consent or approval of the
|
||||||
|
PRB. They can be developed in a completely
|
||||||
|
decentralized manner both by individual OpenStack
|
||||||
|
developers and by commercial vendors. Because
|
||||||
|
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>
|
||||||
|
<para>That said, not all extensions are destined to be
|
||||||
promoted to the next API version. Core APIs always
|
promoted to the next API version. Core APIs always
|
||||||
deals with core functionality — functionality
|
deals with core functionality — functionality that is
|
||||||
that is supported by all implementations and is
|
supported by all implementations and is applicable in
|
||||||
applicable in common cases. Extensions that deal with
|
common cases. Extensions that deal with niche
|
||||||
niche functionality should always remain extensions.
|
functionality should always remain extensions.</para>
|
||||||
</para>
|
<para>The table below summarizes the differences between
|
||||||
<para>
|
versions and extensions.</para>
|
||||||
The table below summarizes the differences between
|
<table rules="all">
|
||||||
versions and extensions.
|
<caption>Versions versus Extensions</caption>
|
||||||
</para>
|
<col width="50%"/>
|
||||||
<table frame="all">
|
<col width="50%"/>
|
||||||
<title>Versions versus Extensions</title>
|
<thead>
|
||||||
<tgroup cols="2">
|
<tr>
|
||||||
<colspec colname="c1" colnum="1" colwidth="1.0*"/>
|
<th>Versions</th>
|
||||||
<colspec colname="c2" colnum="2" colwidth="1.0*"/>
|
<th>Extensions</th>
|
||||||
<thead>
|
</tr>
|
||||||
<row>
|
</thead>
|
||||||
<entry>Versions</entry>
|
<tbody>
|
||||||
<entry>Extensions</entry>
|
<tr>
|
||||||
</row>
|
<td><formalpara>
|
||||||
</thead>
|
<title>Rare</title>
|
||||||
<tbody>
|
<para>Versions provide a stable
|
||||||
<row>
|
platform on which to
|
||||||
<entry>
|
develop.</para>
|
||||||
<formalpara>
|
</formalpara></td>
|
||||||
<title>Rare</title>
|
<td><formalpara>
|
||||||
<para>
|
<title>Frequent</title>
|
||||||
Versions provide a stable
|
<para>Extensions bring new features to
|
||||||
platform on which to develop.
|
the market quickly and in a
|
||||||
</para>
|
compatible manner.</para>
|
||||||
</formalpara>
|
</formalpara></td>
|
||||||
</entry>
|
</tr>
|
||||||
<entry>
|
<tr>
|
||||||
<formalpara>
|
<td>
|
||||||
<title>Frequent</title>
|
<formalpara>
|
||||||
<para>
|
<title>Centralized</title>
|
||||||
Extensions bring new features
|
<para>Versions are maintained by the
|
||||||
to the market quickly and in a
|
entity that controls the API Spec:
|
||||||
compatible manner.
|
the OpenStack Policy Review Board.
|
||||||
</para>
|
Only the PRB can create a new
|
||||||
</formalpara>
|
version; only the PRB defines what
|
||||||
</entry>
|
"OpenStack Compute 1.1"
|
||||||
</row>
|
means.</para>
|
||||||
<row>
|
</formalpara></td>
|
||||||
<entry>
|
<td><formalpara>
|
||||||
<formalpara>
|
<title>Decentralized</title>
|
||||||
<title>Centralized</title>
|
<para>Extensions are maintained by
|
||||||
<para>
|
third parties, including individual
|
||||||
Versions are maintained by the
|
OpenStack developers and software
|
||||||
entity that controls the API
|
vendors. Anyone can create an
|
||||||
Spec: the OpenStack Policy
|
extension.</para>
|
||||||
Review Board. Only the PRB can
|
</formalpara></td>
|
||||||
create a new version; only the
|
</tr>
|
||||||
PRB defines what "OpenStack
|
<tr>
|
||||||
Compute 1.1" means.
|
<td>
|
||||||
</para>
|
<formalpara>
|
||||||
</formalpara>
|
<title>Niche</title>
|
||||||
</entry>
|
<para>Extensions provide specialized
|
||||||
<entry>
|
functionality.</para>
|
||||||
<formalpara>
|
</formalpara></td>
|
||||||
<title>Decentralized</title>
|
<td><formalpara>
|
||||||
<para>
|
<title>Core</title>
|
||||||
Extensions are maintained by
|
<para>Versions support core
|
||||||
third parties, including
|
functionality.</para>
|
||||||
individual OpenStack
|
</formalpara></td>
|
||||||
developers and software
|
</tr>
|
||||||
vendors. Anyone can create an
|
<tr>
|
||||||
extension.
|
<td>
|
||||||
</para>
|
<formalpara>
|
||||||
</formalpara>
|
<title>Query-able</title>
|
||||||
</entry>
|
<para>Issuing a <command>GET</command>
|
||||||
</row>
|
on the base URL (<code>/</code>) of
|
||||||
<row>
|
the API endpoint returns
|
||||||
<entry>
|
information about what versions are
|
||||||
<formalpara>
|
available.</para>
|
||||||
<title>Core</title>
|
</formalpara>
|
||||||
<para>
|
</td>
|
||||||
Versions support core
|
<td>
|
||||||
functionality.
|
<formalpara>
|
||||||
</para>
|
<title>Query-able</title>
|
||||||
</formalpara>
|
<para>Issuing a <command>GET</command>
|
||||||
</entry>
|
on the API's extensions resource
|
||||||
<entry>
|
(<code>/v1.1/extensions</code>)
|
||||||
<formalpara>
|
returns information about what
|
||||||
<title>Niche</title>
|
extensions are available.</para>
|
||||||
<para>
|
</formalpara></td>
|
||||||
Extensions provide specialized
|
</tr>
|
||||||
functionality.
|
</tbody>
|
||||||
</para>
|
|
||||||
</formalpara>
|
|
||||||
</entry>
|
|
||||||
</row>
|
|
||||||
<row>
|
|
||||||
<entry>
|
|
||||||
<formalpara>
|
|
||||||
<title>Queryable</title>
|
|
||||||
<para>
|
|
||||||
Issuing a <command>GET</command> on the base
|
|
||||||
URL (<code>/</code>) of the
|
|
||||||
API endpoint returns
|
|
||||||
information about what
|
|
||||||
versions are available.
|
|
||||||
</para>
|
|
||||||
</formalpara>
|
|
||||||
</entry>
|
|
||||||
<entry>
|
|
||||||
<formalpara>
|
|
||||||
<title>Queryable</title>
|
|
||||||
<para>
|
|
||||||
Issuing a <command>GET</command> on the API's
|
|
||||||
extensions resource
|
|
||||||
(<code>/v1.1/extensions</code>)
|
|
||||||
returns information about what
|
|
||||||
extensions are available.
|
|
||||||
</para>
|
|
||||||
</formalpara>
|
|
||||||
</entry>
|
|
||||||
</row>
|
|
||||||
</tbody>
|
|
||||||
</tgroup>
|
|
||||||
</table>
|
</table>
|
||||||
</section>
|
</section>
|
||||||
<section>
|
<section xml:id="versioning_extensions">
|
||||||
<title>Versioning Extensions</title>
|
<title>Versioning Extensions</title>
|
||||||
<para>There is no explicit versioning mechanism for extensions. Nonetheless, there may
|
<para>There is no explicit versioning mechanism for
|
||||||
be cases in which a developer decides to update an extension after the extension has
|
extensions. Nonetheless, there may be cases in which a
|
||||||
been released and client support for the extension has been established. In these
|
developer decides to update an extension after the
|
||||||
cases, it is recommended that a new extension be created. The extension may have a
|
extension has been released and client support for the
|
||||||
name that signifies its relationship to the previous version. For example, a
|
extension has been established. In these cases, it is
|
||||||
developer may append an integer to the extension name to signify that one extension
|
recommended that a new extension be created. The
|
||||||
updates another: <code>RAX-PIE2</code> updates <code>RAX-PIE</code>.</para>
|
extension may have a name that signifies its
|
||||||
<para>Extensions may have dependencies on other extensions. For example,
|
relationship to the previous version. For example, a
|
||||||
<code>RAX-PIE2</code> may depend on <code>RAX-PIE</code> and may simply add
|
developer may append an integer to the extension name
|
||||||
additional capabilities to it. In general, dependencies of this kind are discouraged
|
to signify that one extension updates another:
|
||||||
and implementers should strive to keep extensions independent. That said, extension
|
<code>RAX-PIE2</code> updates
|
||||||
dependencies allow for the possibility of providing updates to existing extensions
|
<code>RAX-PIE</code>.</para>
|
||||||
even if the original extension is under the control of a different vendor. This is
|
<para>Extensions may have dependencies on other
|
||||||
particularly useful in cases where an existing extension has good client support.</para>
|
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>
|
||||||
</section>
|
</section>
|
||||||
<section>
|
<section xml:id="plug-ability">
|
||||||
<title>Extensions and Pluggability</title>
|
<title>Extensions and Plug-ability</title>
|
||||||
<para>Core APIs abstract away vendor differences in order to provide a cross-platform
|
<para>Core APIs abstract away vendor differences in order
|
||||||
environment to their clients. For example, a client should be able to interact with
|
to provide a cross-platform environment to their
|
||||||
an OpenStack load balancing service without worrying about whether the deployment
|
clients. For example, a client should be able to
|
||||||
utilizes Zeus, Pound, or HAProxy on the backend. OpenStack implementations strive to
|
interact with an OpenStack load balancing service
|
||||||
support multiple backends out of the box. They do so by employing software drivers.
|
without worrying about whether the deployment utilizes
|
||||||
Each driver is responsible for communicating to a specific backend and is in charge
|
Zeus, Pound, or HAProxy on the backend. OpenStack
|
||||||
of translating core API requests to it.</para>
|
implementations strive to support multiple backends
|
||||||
<para>The core API contains only those capabilities which are applicable to all
|
out of the box. They do so by employing software
|
||||||
backends; however, not all backends are created equal, with each backend offering a
|
drivers. Each driver is responsible for communicating
|
||||||
distinct set of capabilities. Extensions play a critical role in exposing these
|
to a specific backend and is in charge of translating
|
||||||
capabilities to clients. This is illustrated below. Here, extensions fill in the gap
|
core API requests to it.</para>
|
||||||
between the common capabilities that the core API provides and the unique
|
<para>The core API contains only those capabilities which
|
||||||
capabilities of the Zeus load balancer. In a sense, one can think of extensions as
|
are applicable to all backends; however, not all
|
||||||
providing frontends to OpenStack plug-ins.</para>
|
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 front ends to OpenStack
|
||||||
|
plug-ins.</para>
|
||||||
<figure xml:id="core-extensions">
|
<figure xml:id="core-extensions">
|
||||||
<title>Extensions and Pluggability</title>
|
<title>Extensions and Plug-ability</title>
|
||||||
<mediaobject>
|
<mediaobject>
|
||||||
<imageobject role="fo">
|
<imageobject role="fo">
|
||||||
<imagedata scale="100" fileref="../figures/apix-1service-core-extensions-manybackends.svg" format="SVG" align="center"/>
|
<imagedata scale="100"
|
||||||
|
fileref="../figures/apix-1service-core-extensions-manybackends.svg"
|
||||||
|
format="SVG" align="center"/>
|
||||||
</imageobject>
|
</imageobject>
|
||||||
<imageobject role="html">
|
<imageobject role="html">
|
||||||
<imagedata fileref="../figures/apix-1service-core-extensions-manybackends.png" format="PNG" align="center"/>
|
<imagedata
|
||||||
|
fileref="../figures/apix-1service-core-extensions-manybackends.png"
|
||||||
|
format="PNG" align="center"/>
|
||||||
</imageobject>
|
</imageobject>
|
||||||
</mediaobject>
|
</mediaobject>
|
||||||
</figure>
|
</figure>
|
||||||
|
|||||||
@ -64,7 +64,7 @@
|
|||||||
<plugin>
|
<plugin>
|
||||||
<groupId>com.rackspace.cloud.api</groupId>
|
<groupId>com.rackspace.cloud.api</groupId>
|
||||||
<artifactId>clouddocs-maven-plugin</artifactId>
|
<artifactId>clouddocs-maven-plugin</artifactId>
|
||||||
<version>1.15.0</version>
|
<version>2.0.2</version>
|
||||||
<executions>
|
<executions>
|
||||||
<execution>
|
<execution>
|
||||||
<goals>
|
<goals>
|
||||||
|
|||||||
Binary file not shown.
|
Before Width: | Height: | Size: 454 B |
Binary file not shown.
|
Before Width: | Height: | Size: 672 B |
@ -1,70 +0,0 @@
|
|||||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
||||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
|
||||||
|
|
||||||
<svg:svg
|
|
||||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
|
||||||
xmlns:cc="http://creativecommons.org/ns#"
|
|
||||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
||||||
xmlns:svg="http://www.w3.org/2000/svg"
|
|
||||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
|
||||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
|
||||||
version="1.0"
|
|
||||||
width="13.895596"
|
|
||||||
height="6.3500013"
|
|
||||||
viewBox="0 0 13.895595 6.3500013"
|
|
||||||
id="svg2868"
|
|
||||||
xml:space="preserve"
|
|
||||||
inkscape:version="0.48.0 r9654"
|
|
||||||
sodipodi:docname="Arrow_east.svg"><svg:metadata
|
|
||||||
id="metadata3857"><rdf:RDF><cc:Work
|
|
||||||
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
|
|
||||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></svg:metadata><sodipodi:namedview
|
|
||||||
pagecolor="#ffffff"
|
|
||||||
bordercolor="#666666"
|
|
||||||
borderopacity="1"
|
|
||||||
objecttolerance="10"
|
|
||||||
gridtolerance="10"
|
|
||||||
guidetolerance="10"
|
|
||||||
inkscape:pageopacity="0"
|
|
||||||
inkscape:pageshadow="2"
|
|
||||||
inkscape:window-width="1131"
|
|
||||||
inkscape:window-height="740"
|
|
||||||
id="namedview3855"
|
|
||||||
showgrid="false"
|
|
||||||
inkscape:zoom="11.313708"
|
|
||||||
inkscape:cx="8.6182271"
|
|
||||||
inkscape:cy="-2.2709277"
|
|
||||||
inkscape:window-x="0"
|
|
||||||
inkscape:window-y="0"
|
|
||||||
inkscape:window-maximized="0"
|
|
||||||
inkscape:current-layer="svg2868"
|
|
||||||
fit-margin-top="0"
|
|
||||||
fit-margin-left="0"
|
|
||||||
fit-margin-right="0"
|
|
||||||
fit-margin-bottom="0" /><svg:defs
|
|
||||||
id="defs2874" />
|
|
||||||
|
|
||||||
|
|
||||||
<namedview
|
|
||||||
pagecolor="#ffffff"
|
|
||||||
bordercolor="#666666"
|
|
||||||
borderopacity="1.0"
|
|
||||||
pageopacity="0.0"
|
|
||||||
pageshadow="2"
|
|
||||||
window-width="640"
|
|
||||||
window-height="541"
|
|
||||||
zoom="0.34493828"
|
|
||||||
cx="372.04722"
|
|
||||||
cy="256.66814"
|
|
||||||
window-x="75"
|
|
||||||
window-y="152"
|
|
||||||
current-layer="svg2033">
|
|
||||||
</namedview>
|
|
||||||
<svg:g
|
|
||||||
transform="matrix(-0.01540104,0,0,-0.01741068,13.895596,6.3500014)"
|
|
||||||
id="Ebene_1">
|
|
||||||
<svg:polygon
|
|
||||||
points="902.25049,222.98633 233.17773,222.98633 233.17773,364.71875 0,182.35938 233.17773,0 233.17773,141.73242 902.25049,141.73242 902.25049,222.98633 "
|
|
||||||
id="path2050" />
|
|
||||||
</svg:g>
|
|
||||||
</svg:svg>
|
|
||||||
|
Before Width: | Height: | Size: 2.1 KiB |
@ -1,60 +0,0 @@
|
|||||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|
||||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
|
||||||
<svg
|
|
||||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
|
||||||
xmlns:cc="http://web.resource.org/cc/"
|
|
||||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
||||||
xmlns:svg="http://www.w3.org/2000/svg"
|
|
||||||
xmlns="http://www.w3.org/2000/svg"
|
|
||||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
|
||||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
|
||||||
width="19.21315"
|
|
||||||
height="18.294994"
|
|
||||||
id="svg2"
|
|
||||||
sodipodi:version="0.32"
|
|
||||||
inkscape:version="0.45"
|
|
||||||
sodipodi:modified="true"
|
|
||||||
version="1.0">
|
|
||||||
<defs
|
|
||||||
id="defs4" />
|
|
||||||
<sodipodi:namedview
|
|
||||||
id="base"
|
|
||||||
pagecolor="#ffffff"
|
|
||||||
bordercolor="#666666"
|
|
||||||
borderopacity="1.0"
|
|
||||||
gridtolerance="10000"
|
|
||||||
guidetolerance="10"
|
|
||||||
objecttolerance="10"
|
|
||||||
inkscape:pageopacity="0.0"
|
|
||||||
inkscape:pageshadow="2"
|
|
||||||
inkscape:zoom="7.9195959"
|
|
||||||
inkscape:cx="17.757032"
|
|
||||||
inkscape:cy="7.298821"
|
|
||||||
inkscape:document-units="px"
|
|
||||||
inkscape:current-layer="layer1"
|
|
||||||
inkscape:window-width="984"
|
|
||||||
inkscape:window-height="852"
|
|
||||||
inkscape:window-x="148"
|
|
||||||
inkscape:window-y="66" />
|
|
||||||
<metadata
|
|
||||||
id="metadata7">
|
|
||||||
<rdf:RDF>
|
|
||||||
<cc:Work
|
|
||||||
rdf:about="">
|
|
||||||
<dc:format>image/svg+xml</dc:format>
|
|
||||||
<dc:type
|
|
||||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
|
||||||
</cc:Work>
|
|
||||||
</rdf:RDF>
|
|
||||||
</metadata>
|
|
||||||
<g
|
|
||||||
inkscape:label="Layer 1"
|
|
||||||
inkscape:groupmode="layer"
|
|
||||||
id="layer1"
|
|
||||||
transform="translate(-192.905,-516.02064)">
|
|
||||||
<path
|
|
||||||
style="fill:#000000"
|
|
||||||
d="M 197.67968,534.31563 C 197.40468,534.31208 196.21788,532.53719 195.04234,530.37143 L 192.905,526.43368 L 193.45901,525.87968 C 193.76371,525.57497 194.58269,525.32567 195.27896,525.32567 L 196.5449,525.32567 L 197.18129,527.33076 L 197.81768,529.33584 L 202.88215,523.79451 C 205.66761,520.74678 208.88522,517.75085 210.03239,517.13691 L 212.11815,516.02064 L 207.90871,520.80282 C 205.59351,523.43302 202.45735,527.55085 200.93947,529.95355 C 199.42159,532.35625 197.95468,534.31919 197.67968,534.31563 z "
|
|
||||||
id="path2223" />
|
|
||||||
</g>
|
|
||||||
</svg>
|
|
||||||
|
Before Width: | Height: | Size: 2.1 KiB |
46
pom.xml
Normal file
46
pom.xml
Normal file
@ -0,0 +1,46 @@
|
|||||||
|
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
||||||
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||||
|
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
|
||||||
|
<modelVersion>4.0.0</modelVersion>
|
||||||
|
|
||||||
|
<groupId>org.openstack.docs</groupId>
|
||||||
|
<artifactId>parent-pom</artifactId>
|
||||||
|
<version>1.0.0-SNAPSHOT</version>
|
||||||
|
<packaging>pom</packaging>
|
||||||
|
|
||||||
|
<modules>
|
||||||
|
<!-- <module>v1.0</module>--> <!-- do not build this one -->
|
||||||
|
<module>v2</module>
|
||||||
|
</modules>
|
||||||
|
<profiles>
|
||||||
|
<profile>
|
||||||
|
<id>Rackspace Research Repositories</id>
|
||||||
|
<activation>
|
||||||
|
<activeByDefault>true</activeByDefault>
|
||||||
|
</activation>
|
||||||
|
<repositories>
|
||||||
|
<repository>
|
||||||
|
<id>rackspace-research</id>
|
||||||
|
<name>Rackspace Research Repository</name>
|
||||||
|
<url>http://maven.research.rackspacecloud.com/content/groups/public/</url>
|
||||||
|
</repository>
|
||||||
|
</repositories>
|
||||||
|
<pluginRepositories>
|
||||||
|
<pluginRepository>
|
||||||
|
<id>rackspace-research</id>
|
||||||
|
<name>Rackspace Research Repository</name>
|
||||||
|
<url>http://maven.research.rackspacecloud.com/content/groups/public/</url>
|
||||||
|
</pluginRepository>
|
||||||
|
</pluginRepositories>
|
||||||
|
</profile>
|
||||||
|
</profiles>
|
||||||
|
<build>
|
||||||
|
<plugins>
|
||||||
|
<plugin>
|
||||||
|
<groupId>com.rackspace.cloud.api</groupId>
|
||||||
|
<artifactId>clouddocs-maven-plugin</artifactId>
|
||||||
|
<version>2.0.2</version>
|
||||||
|
</plugin>
|
||||||
|
</plugins>
|
||||||
|
</build>
|
||||||
|
</project>
|
||||||
@ -2,40 +2,24 @@
|
|||||||
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
||||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
|
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
|
||||||
|
<parent>
|
||||||
|
<groupId>org.openstack.docs</groupId>
|
||||||
|
<artifactId>parent-pom</artifactId>
|
||||||
|
<version>1.0.0-SNAPSHOT</version>
|
||||||
|
<relativePath>../pom.xml</relativePath>
|
||||||
|
</parent>
|
||||||
<modelVersion>4.0.0</modelVersion>
|
<modelVersion>4.0.0</modelVersion>
|
||||||
|
<artifactId>openstack-compute-api-v1</artifactId>
|
||||||
<groupId>org.openstack.docs</groupId>
|
|
||||||
<artifactId>openstack-guide</artifactId>
|
|
||||||
<version>1.0.0-SNAPSHOT</version>
|
|
||||||
<packaging>jar</packaging>
|
<packaging>jar</packaging>
|
||||||
<name>OpenStack Compute Developer Guide API 1.0</name>
|
<name>OpenStack Compute API v1.0 Reference</name>
|
||||||
|
<properties>
|
||||||
|
<!-- This is set by Jenkins according to the branch. -->
|
||||||
|
<release.path.name>local</release.path.name>
|
||||||
|
<comments.enabled>1</comments.enabled>
|
||||||
|
</properties>
|
||||||
<!-- ################################################ -->
|
<!-- ################################################ -->
|
||||||
<!-- USE "mvn clean generate-sources" to run this POM -->
|
<!-- USE "mvn clean generate-sources" to run this POM -->
|
||||||
<!-- ################################################ -->
|
<!-- ################################################ -->
|
||||||
<profiles>
|
|
||||||
<profile>
|
|
||||||
<id>Rackspace Research Repositories</id>
|
|
||||||
<activation>
|
|
||||||
<activeByDefault>true</activeByDefault>
|
|
||||||
</activation>
|
|
||||||
<repositories>
|
|
||||||
<repository>
|
|
||||||
<id>rackspace-research</id>
|
|
||||||
<name>Rackspace Research Repository</name>
|
|
||||||
<url>http://maven.research.rackspacecloud.com/content/groups/public/</url>
|
|
||||||
</repository>
|
|
||||||
</repositories>
|
|
||||||
<pluginRepositories>
|
|
||||||
<pluginRepository>
|
|
||||||
<id>rackspace-research</id>
|
|
||||||
<name>Rackspace Research Repository</name>
|
|
||||||
<url>http://maven.research.rackspacecloud.com/content/groups/public/</url>
|
|
||||||
</pluginRepository>
|
|
||||||
</pluginRepositories>
|
|
||||||
</profile>
|
|
||||||
</profiles>
|
|
||||||
|
|
||||||
<build>
|
<build>
|
||||||
<sourceDirectory>src</sourceDirectory>
|
<sourceDirectory>src</sourceDirectory>
|
||||||
<resources>
|
<resources>
|
||||||
@ -47,11 +31,10 @@
|
|||||||
</resource>
|
</resource>
|
||||||
</resources>
|
</resources>
|
||||||
<plugins>
|
<plugins>
|
||||||
|
|
||||||
<plugin>
|
<plugin>
|
||||||
<groupId>com.rackspace.cloud.api</groupId>
|
<groupId>com.rackspace.cloud.api</groupId>
|
||||||
<artifactId>clouddocs-maven-plugin</artifactId>
|
<artifactId>clouddocs-maven-plugin</artifactId>
|
||||||
<version>1.15.0</version>
|
<!-- version is set in ../pom.xml file -->
|
||||||
<executions>
|
<executions>
|
||||||
<execution>
|
<execution>
|
||||||
<id>goal1</id>
|
<id>goal1</id>
|
||||||
@ -93,7 +76,6 @@
|
|||||||
<sectionLabelIncludesComponentLabel>0</sectionLabelIncludesComponentLabel>
|
<sectionLabelIncludesComponentLabel>0</sectionLabelIncludesComponentLabel>
|
||||||
<postProcess>
|
<postProcess>
|
||||||
<!-- Copies the figures to the correct location for webhelp -->
|
<!-- Copies the figures to the correct location for webhelp -->
|
||||||
|
|
||||||
<!-- Why is this necessary? -->
|
<!-- Why is this necessary? -->
|
||||||
<mkdir dir="${basedir}/target/docbkx/webhelp/openstack-compute-api-1.0/cs-devguide"/>
|
<mkdir dir="${basedir}/target/docbkx/webhelp/openstack-compute-api-1.0/cs-devguide"/>
|
||||||
<copy
|
<copy
|
||||||
@ -103,12 +85,10 @@
|
|||||||
<include name="**/*" />
|
<include name="**/*" />
|
||||||
</fileset>
|
</fileset>
|
||||||
</copy>
|
</copy>
|
||||||
|
|
||||||
<!--Moves PDFs to the needed placement -->
|
<!--Moves PDFs to the needed placement -->
|
||||||
<move failonerror="false"
|
<move failonerror="false"
|
||||||
file="${basedir}/target/docbkx/pdf/openstack-compute-api-1.0/cs-devguide.pdf"
|
file="${basedir}/target/docbkx/pdf/openstack-compute-api-1.0/cs-devguide.pdf"
|
||||||
tofile="${basedir}/target/docbkx/webhelp/trunk/openstack-compute/developer/openstack-compute-api-1.0/cs-devguide-trunk.pdf"/>
|
tofile="${basedir}/target/docbkx/webhelp/trunk/openstack-compute/developer/openstack-compute-api-1.0/cs-devguide-trunk.pdf"/>
|
||||||
|
|
||||||
<!--Deletes leftover unneeded directories -->
|
<!--Deletes leftover unneeded directories -->
|
||||||
<delete
|
<delete
|
||||||
dir="${basedir}/target/docbkx/webhelp/openstack-compute-api-1.0"/>
|
dir="${basedir}/target/docbkx/webhelp/openstack-compute-api-1.0"/>
|
||||||
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user