/) of the API endpoint returns information about what
+ versions are available. Similarly, issuing a /v1.1/extensions) returns information about what extensions are
+ available. (See
+ extensions
+ resource itself is always accessed at a particular version. RAX-PIE2 updates RAX-PIE. RAX-PIE2 may depend on RAX-PIE and may simply add
+ additional capabilities to it. In general, dependencies of this kind are discouraged
+ and implementers should strive to keep extensions independent. That said, extension
+ dependencies allow for the possibility of providing updates to existing extensions
+ even if the original extension is under the control of a different vendor. This is
+ particularly useful in cases where an existing extension has good client support. Contents
+ This chapter provides background information on OpenStack + extensions and the OpenStack extension mechanism. It + describes what extensions are, how the extension mechanism + in OpenStack is related to the OpenGL extension mechanism, + the differences between extensions and versions, the + concept of versioning extensions, and why extensions are + vital when defining a pluggable architecture. +
+ The OpenStack extension mechanism makes it possible to add + functionality to OpenStack APIs in a manner that ensures + compatibility with existing clients. This capability + allows OpenStack operators and vendors to provide + innovative functionality to their clients and provides a + means by which new features may be considered in upcoming + versions of OpenStack APIs. +
+ This document describes the extension mechanism in detail. + It provides guidance to API implementors and clients on + developing and consuming API extensions, it describes the + rules by which extensions are governed, and it describes + the process used to promote API extensions to new features. +
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:
ReSTful web services
HTTP/1.1
JSON and/or XML data serialization formats
At least one OpenStack API: Compute, + Object Storage, etc.
+ Provides background information on + OpenStack extensions and the OpenStack + extension mechanism. +
+ Describes the specifics of implementing + and consuming extensions in ReST APIs. +
+ Describes API governance and the process + by which extensions can be promoted to new + features in future revisions of an API. +
Briefly summarizes the benefits of the extension mechanism and + provides a brief overview of how extensions are used.
| Revision Date | +Summary of Changes | +|||
| June 10, 2011 | +
+
|
+ |||
+ OpenStack APIs are defined strictly in two forms: a + human-readable specification (usually in the form of a + developer's guide) and a machine-processable + WADL. These specifications define the core actions, + capabilities, and media-types of the API. A client can + always depend on the availability of this + core API and implementers are + always required to support it in its entirety. Requiring strict adherence to the + core API allows clients to rely upon a minimal level + of functionality when interacting with multiple + implementations of the same API. +
+ Note that it is quite possible that distinct + implementations of an OpenStack API exist. First + because API specifications are released under a free + license, so anyone may use them to implement a core + API. Furthermore, the OpenStack implementations + themselves are released under a free license, making + it possible to alter the code to create a specialized + version. Such a specialized implementation could + remain OpenStack-compatible even if it were to + implement new features or add new capabilities, but + only if it made the changes in a manner that ensures + that a client expecting a core API would continue to + function normally — this is where extensions + come in. +
An extension adds capabilities to an API beyond those + defined in the core. The introduction of new features, MIME types, actions, states, + headers, parameters, and resources can all be accomplished by means of extensions to + the core API. In order for extensions to work, the core API must be written in such + a manner that it allows for extensibility. Additionally, care should be taken to + ensure that extensions defined by different implementers don't clash with one + another, that clients can detect the presence of extensions via a standard method, + and that there is a clear promotion path at the end of which an extension may become + part of a future version of the core API. These actions, rules, and processes + together form the extension mechanism. It is important that + core APIs adhere to this mechanism in order to ensure compatibility as new + extensions are defined. Note also that while a core API may be written to allow for + extensibility, the extensions themselves are never part of the core.
+ In the 1990s, OpenGL was developed as a portable open + graphics library standard. The goal was to provide a + cross-platform library that could enable developers to + produce 3D graphics at real time speeds (30-120 frames + per second). There were several major challenges to + meeting this goal. In order to be considered an open + standard, control needed to shift from Silicon + Graphics (SGI), who originally developed OpenGL, to an + independent Architecture Review Board (ARB) who would + be responsible for approving specification changes, + marking new releases, and ensuring conformance + testing. Additionally, the graphics library itself + would need to be designed in a manner that would allow + the establishment of a stable and portable platform + for developers. Finally, the library would need to + garner the support of graphics hardware vendors as + they would be providing the hardware acceleration + needed to meet the goal of performing at real-time + speeds. +
Gaining vendor support is challenging because vendors are often in direct + competition with one another. They differentiate themselves by creating innovative + new features and by providing niche functionality to their users. Thus, OpenGL was + faced with two competing requirements. On the one hand, it needed to abstract away + vendor differences in order to provide a stable cross-platform environment to + developers. On the other hand, in order to garner vendor support, it needed a method + by which vendors could differentiate themselves and provide innovative new features + and niche functionality to their users.
The OpenGL extension mechanism was developed to solve these problems. The + 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 + specification remained uncluttered and presented a unified view of common + functionality. Because extensions were detectable at run time, developers could + write portable applications that could adapt to the hardware on which they were + running. This method of allowing for an extensible API has proven to be a very + successful strategy. More than 500 extensions have been defined in OpenGL's lifetime + and many vendors, including NVidia, ATI, Apple, IBM, and Intel, have participated in + the process by developing their own custom extensions. Additionally, many key + innovations (such as vertex and fragment shaders) have been developed via the + extension process and are now part of the core OpenGL API.
OpenStack, while very different from OpenGL, shares many similar goals and faces + 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 + 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.
Extensions are always interpreted in relation to a version of the core API. In + other words, from a client's perspective, an extension modifies a + particular version of the core API in some way. In reality, an + extension may be applicable to several versions of an API at once. For example, a + particular extension may continue to be available as a core API moves from one + version to another. In fact, different implementations may decide to include support + for an extension at different versions. As explained in + , + 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.
![[Note]](../common/images/admon/note.png) | Note |
|---|---|
+ As always, implementers are not required to + support an extension unless it is promoted to the + core. + |
Because several versions of the core API may be supported simultaneously, and
+ because each version may offer support for a different set of extensions, clients
+ must be able to detect what versions and extensions are available in a particular
+ deployment. Thus, both extensions and versions are queryable. Issuing a GET on the
+ base URL (/) of the API endpoint returns information about what
+ versions are available. Similarly, issuing a GET on the API's extensions resource
+ (/v1.1/extensions) returns information about what extensions are
+ available. (See
+
+ for details of such requests.) Note that,
+ since extensions modify a particular version of the API, the extensions
+ resource itself is always accessed at a particular version.
Backward-compatible changes in an API usually require a minor version bump. In an + 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 + 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.
+ That said, not all extensions are destined to be + promoted to the next API version. Core APIs always + deals with core functionality — functionality + that is supported by all implementations and is + applicable in common cases. Extensions that deal with + niche functionality should always remain extensions. +
+ The table below summarizes the differences between + versions and extensions. +
Table 2.1. Versions versus Extensions
| Versions | Extensions |
|---|---|
|
+ Rare. + Versions provide a stable + platform on which to develop. + + |
+ Frequent. + Extensions bring new features + to the market quickly and in a + compatible manner. + + |
|
+ Centralized. + Versions are maintained by the + entity that controls the API + Spec: the OpenStack Policy + Review Board. Only the PRB can + create a new version; only the + PRB defines what "OpenStack + Compute 1.1" means. + + |
+ Decentralized. + Extensions are maintained by + third parties, including + individual OpenStack + developers and software + vendors. Anyone can create an + extension. + + |
|
+ Core. + Versions support core + functionality. + + |
+ Niche. + Extensions provide specialized + functionality. + + |
|
+ Queryable.
+ Issuing a GET on the base
+ URL ( |
+ Queryable.
+ Issuing a GET on the API's
+ extensions resource
+ ( |
There is no explicit versioning mechanism for extensions. Nonetheless, there may
+ be cases in which a developer decides to update an extension after the extension has
+ been released and client support for the extension has been established. In these
+ cases, it is recommended that a new extension be created. The extension may have a
+ name that signifies its relationship to the previous version. For example, a
+ developer may append an integer to the extension name to signify that one extension
+ updates another: RAX-PIE2 updates RAX-PIE.
Extensions may have dependencies on other extensions. For example,
+ RAX-PIE2 may depend on RAX-PIE and may simply add
+ additional capabilities to it. In general, dependencies of this kind are discouraged
+ and implementers should strive to keep extensions independent. That said, extension
+ dependencies allow for the possibility of providing updates to existing extensions
+ even if the original extension is under the control of a different vendor. This is
+ particularly useful in cases where an existing extension has good client support.
Core APIs abstract away vendor differences in order to provide a cross-platform + environment to their clients. For example, a client should be able to interact with + an OpenStack load balancing service without worrying about whether the deployment + utilizes Zeus, Pound, or HAProxy on the backend. OpenStack implementations strive to + support multiple backends out of the box. They do so by employing software drivers. + Each driver is responsible for communicating to a specific backend and is in charge + of translating core API requests to it.
The core API contains only those capabilities which are applicable to all + 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.
Copyright © 2010, 2011 Rackspace US, Inc.
+ Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at +
http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +
2011-06-10
Abstract
+ This document provides an overview of the OpenStack API extension + mechanism. +
List of Figures
List of Tables
" + txt_results_for + " " + "" + fileAndWordList[i][0].motslisteDisplay + "" + "
"); + + linkTab.push("" + txt_results_for + " " + "" + cleanwordsList + "" + "
"+"
"; + //write("
" + "Your search returned no results for " + "" + txt_wordsnotfound + "" + "
"; + } + //alert(results); + document.getElementById('searchResults').innerHTML = results; +} + +function tokenize(wordsList){ + var stemmedWordsList = new Array(); // Array with the words to look for after removing spaces + var cleanwordsList = new Array(); // Array with the words to look for + for(var j in wordsList){ + var word = wordsList[j]; + if(typeof stemmer != "undefined" ){ + stemQueryMap[stemmer(word)] = word; + } else { + stemQueryMap[word] = word; + } + } + //stemmedWordsList is the stemmed list of words separated by spaces. + for (var t in wordsList) { + wordsList[t] = wordsList[t].replace(/(%22)|^-/g, ""); + if (wordsList[t] != "%20") { + scriptLetterTab.add(wordsList[t].charAt(0)); + cleanwordsList.push(wordsList[t]); + } + } + + if(typeof stemmer != "undefined" ){ + //Do the stemming using Porter's stemming algorithm + for (var i = 0; i < cleanwordsList.length; i++) { + var stemWord = stemmer(cleanwordsList[i]); + stemmedWordsList.push(stemWord); + } + } else { + stemmedWordsList = cleanwordsList; + } + return stemmedWordsList; +} + +//Invoker of CJKTokenizer class methods. +function cjkTokenize(wordsList){ + var allTokens= new Array(); + var notCJKTokens= new Array(); + var j=0; + for(j=0;j
X-Auth-Token.
+ Clients obtain this token, along with the Cloud Servers API URL, by first using the
+ Rackspace Cloud Authentication Service and supplying a valid username and API access
+ key. X-Auth-User x-header.
+ X-Auth-User
+ x-header.
+ X-Server-Management-Url,
+ X-Storage-Url, X-CDN-Management-Url, as well as
+ X-Auth-Token. An HTTP status of X-Server-Management-Url (which is dynamic and subject to change)
+ and must include the X-Auth-Token header as noted above. The URLs
+ specified in X-Storage-Url and X-CDN-Management-Url
+ are specific to the Cloud Files product and may be ignored for purposes of
+ interacting with Cloud Servers. X-Server-Management-Url
+ that is returned from the authentication system. For
+ example, in the sample response above, you would list
+ servers by performing a &GET; against https://servers.api.rackspacecloud.com/v1.0/35428/servers.
+ Content-Type header
+ and is required for operations that have a request
+ body. The response format can be specified in
+ requests using either the Accept header
+ or adding an .xml or .json extension to the request
+ URI. Note that it is possible for a response to be
+ serialized using a format different from the request
+ (see example below). If no response format is
+ specified, JSON is the default. If conflicting
+ formats are specified using both an
+ Accept header and a query extension, the
+ query extension takes precedence.
+ | Format | +Accept Header | +Query Extension | +Default | +
| JSON | +application/json | +.json | +Yes | +
| XML | +application/xml | +.xml | +No | +
Accept header. An alternative
+ method of achieving the same result is illustrated
+ below – this time we utilize a URI extension instead
+ of an Accept header.
+ Accept-Encoding
+ header on the request from the client and indicated by
+ the Content-Encoding header in the server
+ response. Unless the header is explicitly set,
+ encoding defaults to disabled.
+ | Header Type | +Name | +Value | +
| HTTP/1.1 Request | +Accept-Encoding |
+ gzip | +
| HTTP/1.1 Response | +Content-Encoding |
+ gzip | +
| Header | +Description | +||
Last-Modified |
+ Date and time when the entity was last updated in cache. | +||
| Verb | +URI | +RegEx | +Default | +||
| &POST; | +* | +.* | +10/min | +||
| &POST; | +*/servers | +^/servers | +50/day | +||
| &PUT; | +* | +.* | +10/min | +||
| &GET; | +*changes-since* | +changes-since | +3/min | +||
| &DELETE; | +* | +.* | +100/min | +||
Reply-After header to
+ notify the client when they can attempt to try
+ again.
+ | Limit | +Default | +||
| Maximum total amount of + RAM (GB) | +50 | +||
| Maximum number of shared + IP groups | +25 | +||
| Maximum number of members + per shared IP group | +25 | +||
DEPRECATED. Rackspace will work with
+ developers and partners to ensure there is adequate
+ time to migrate to the new version before deprecated
+ versions are discontinued.
+ | Fault Element | +Associated Error Codes | +Expected in All Requests? | +
| cloudServersFault | +500, 400, other codes possible | +&CHECK; | +
| serviceUnavailable | +503 | +&CHECK; | +
| unauthorized | +401 | +&CHECK; | +
| badRequest | +400 | +&CHECK; | +
| overLimit | +413 | +&CHECK; | +
| badMediaType | +415 | ++ |
| badMethod | +405 | ++ |
| itemNotFound | +404 | ++ |
| buildInProgress | +409 | ++ |
| serverCapacityUnavailable | +503 | ++ |
| backupOrResizeInProgress | +409 | ++ |
| resizeNotAllowed | +403 | ++ |
| notImplemented | +501 | ++ |
ACTIVE status are
+ available for use. Other possible values for the
+ status attribute include: BUILD,
+ REBUILD, SUSPENDED,
+ QUEUE_RESIZE,
+ PREP_RESIZE, RESIZE,
+ VERIFY_RESIZE, PASSWORD,
+ RESCUE, REBOOT,
+ HARD_REBOOT, SHARE_IP,
+ SHARE_IP_NO_CONFIG,
+ DELETE_IP, and UNKNOWN.
+ BUILD &ARROW; ACTIVE
+ BUILD &ARROW; ERROR (on error)
+ -r--r----- ).
+ ACTIVE &ARROW;
+ PASSWORD &ARROW;
+ ACTIVE
+ ACTIVE &ARROW;
+ DELETED
+ SUSPENDED &ARROW;
+ DELETED
+ ACTIVE &ARROW;
+ SHARE_IP &ARROW;
+ ACTIVE (if
+ ACTIVE &ARROW;
+ SHARE_IP_NO_CONFIG &ARROW;
+ ACTIVE
+ ACTIVE &ARROW;
+ DELETE_IP &ARROW;
+ ACTIVE
+ ACTIVE &ARROW;
+ REBOOT &ARROW;
+ ACTIVE (ACTIVE &ARROW;
+ HARD_REBOOT &ARROW;
+ ACTIVE (SOFT), the operating system is signaled to
+ restart, which allows for a graceful shutdown of
+ all processes. A hard reboot (HARD) is the
+ equivalent of power cycling the server.
+ ACTIVE &ARROW;
+ REBUILD &ARROW;
+ ACTIVE
+ ACTIVE &ARROW;
+ REBUILD &ARROW;
+ ERROR (on error)
+ ACTIVE &ARROW;
+ QUEUE_RESIZE &ARROW;
+ PREP_RESIZE &ARROW;
+ RESIZE &ARROW;
+ VERIFY_RESIZE
+ ACTIVE &ARROW;
+ QUEUE_RESIZE &ARROW;
+ ACTIVE (on error)
+ VERIFY_RESIZE &ARROW;
+ ACTIVE
+ VERIFY_RESIZE &ARROW;
+ ACTIVE
+ SAVING and the conditional
+ progress element (0-100% completion) will also be
+ returned. Other possible values for the status
+ attribute include: UNKNOWN,
+ PREPARING, ACTIVE,
+ QUEUED, FAILED. Images
+ with an ACTIVE status are available
+ for install.
+ QUEUED &ARROW; PREPARING &ARROW;
+ SAVING &ARROW; ACTIVE
+ QUEUED &ARROW; PREPARING &ARROW;
+ SAVING &ARROW; FAILED (on error)
+ | Value | +Day | +
| DISABLED | +Weekly backup disabled | +
| SUNDAY | +Sunday | +
| MONDAY | +Monday | +
| TUESDAY | +Tuesday | +
| WEDNESDAY | +Wednesday | +
| THURSDAY | +Thursday | +
| FRIDAY | +Friday | +
| SATURDAY | +Saturday | +
| Value | +Hour Range | +
| DISABLED | +Daily backups disabled | +
| H_0000_0200 | +0000-0200 | +
| H_0200_0400 | +0200-0400 | +
| H_0400_0600 | +0400-0600 | +
| H_0600_0800 | +0600-0800 | +
| H_0800_1000 | +0800-1000 | +
| H_1000_1200 | +1000-1200 | +
| H_1200_1400 | +1200-1400 | +
| H_1400_1600 | +1400-1600 | +
| H_1600_1800 | +1600-1800 | +
| H_1800_2000 | +1800-2000 | +
| H_2000_2200 | +2000-2200 | +
| H_2200_0000 | +2200-0000 | +
+ This schema file defines actions that can be performed on a + cloud server. All cloud server actions are derived from the Action type. +
++ Performs a HARD or SOFT reboot. +
++ Rebuilds a server. +
++ Resizes a server. +
++ Confirms a resize action. +
++ Reverts a resize action. +
++ This is the base type for all server actions. It is simply + a marker abstract type used to differentiate an Action + element from other elements. +
++ The type of reboot to perform. +
++ The id of an image to use for the rebuild. +
++ The id of the flavor to convert to. +
++ A HARD reboot is equivalent to power cycling the server. + The operating system is not allowed to gracefully + shutdown. +
++ With a SOFT reboot, the operating system is signaled to + restart. This allows for a graceful shutdown of all + processes. +
++ The following is a list of custom annotations that are used in + XML Schema descriptions for version 1.0 of the Cloud Servers + API. Each annotation is defined as a single XML element in + the + http://docs.rackspacecloud.com/xsd-ext/v1.0 namespace. + These elements can be added as annotations via the appinfo + schema tag. +
++ Annotations allow useful meta-data to be associated with the + schema types. For example, a root element of a particular type + can be associated with a sample document that illustrates its + usage. Annotations also provide hints when converting schema + into presentation markups such as XHTML, Docbook, and Open + Document Format. +
++ Aside from custom elements, schema types in the Cloud Servers + API are also annotated with documentation tags. These tags + always contain text in XHTML 1.1 block elements. +
++ Get access to the xml: attribute groups for xml:lang needed + by the Documentation type. +
++ This is a meta-annotation, it is only used only when + defining another annotation and provides information about + the annotation. +
++ Used to embed a fragment of code in the documentation text. +
++ Defines a text based title for the current schema document. + The title is used when converting the schema to presentation + markup. +
++ This tag is a template tag. It places content as is in a + document when converting the schema to some presentation + type. The presentation type is specified with the type + attribute. The contents of head should be well-formed + XML. This places content in the document header (think + html:head) when converting the schema to presentation + markup. See the header tag to place content at the top of + the body content. +
++ This tag is a template tag. It places content as is in a + document when converting the schema to some presentation + type. The presentation type is specified with the type + attribute. The contents of header should be well-formed + XML. This places content on the top of the presentation + markup -- for XHTML this places content right after the + html:body tag. See the head tag to place content in the + document header. +
++ This tag is a template tag. It places content as is in a + document when converting the schema to some presentation + type. The presentation type is specified with the type + attribute. The contents of footer should be well-formed + XML. This places content on the bottom of the presentation + markup -- for XHTML this places content before closing the + html:body tag. See the header tag to place content in the + beginning of the document. +
++ Samples provides a means of displaying several versions of + the same code sample. We can do this to display the same + sample in various formats: XML, JSON. Each sample can + contain an optional description and a code element. +
++ The link annotation establishes one or more relationships + from a particular Schema document to another file. This is + useful for establishing links between pages when converting + to a presentation markup. +
++ In this example, we note that the schema file is indexed + by file index.xsd. Also, there is an alternative version + of this file (schema.rnc) in RelaxNG Compact Syntax. +
++ Here we denote a reverse link. We are saying this file + serves as an index to file schema.xsd. +
++ This type provides information about a custom annotation. +
++ Used to capture documentation usually as XHTML. +
++ A template places content as is in a document when + converting the schema to some presentation type. The + presentation type is specified with the type attribute. +
++ Language defines the type of content in the template. It + should be a mime-type. XHTML is assumed if type is not + specified. +
++ Used to provide example instances of schema elements. +
++ An optional description or summary of the example. +
++ The example code. +
++ A descriptive title for the sample, the type attribute may + be used as a title if this attribute is not specified. +
++ A collection of samples. +
++ An optional description or summary of the example. +
++ A list of samples to display. +
++ Source code that may be provided inline or that may be + referenced via an href attribute. +
++ This provides a link to the source code. If both the + in-line text and the href parameter are specified, + in-line text will be ignored. +
++ A mime type describing the source code. +
++ Used to establish relationships between documents. +
++ When linking to an XML document, denotes the QName of the + element to link to. This is usually used when linking + with foreign schema elements. +
++ A mime type describing the type of link. +
++ The relationships from the current document to the + document pointed to by the href attribute. +
++ The relationships from the document pointed to by the href + attribute to the current document. +
++ A list of document relationships separated by whitespace. +
++ A document relationship used in link elements. In order to + remain flexible, this is not a finite + enumeration. In practice, however, only three relationships + are currently supported: alternate, index, + and schema. The alternate forward + relationship denotes that the linked document can be used as + an alternative to the current document. The index + forward relationship that the link document is an index to + the current document. Finally, the schema + relationship denotes that a schema element from the link + document is used in the current document. +
++ A list of annotation types separated by whitespace. +
++ This enumeration describes where a custom annotation can be + applied. +
++ The annotation can be applied to the schema tag. +
++ The annotation can be applied to the element tag. +
++ The annotation can be embedded in the documentation tag + of any schema element. +
++ The annotation can be applied to any element in the XML + Schema namespace. +
++ This is the main index XML Schema document + for the Cloud Servers API. +
++ Servers and all internal Entities including: Addresses, + Files, and MetaData. +
++ Types related to images. +
++ Types related to flavors. +
++ Types related to shared IP groups. +
++ Types related to backup schedules. +
++ Defines server actions: reboot, rebuild, resize... +
++ All fault types. +
++ Types related to rate and absolute limits. +
++ Types related to API version details. +
++ This schema file defines all entities related to Backup Schedules. +
++ This element is used to create periodic daily and weekly + images automatically. +
++ If true, both daily and weekly backup schedules are + disabled. +
++ A WeeklyBackup type that describes the day + of the week in which to perform a weekly backup or + DISABLED if weekly backups are disabled. +
++ A DailyBackup type that describes an hour + range in which to perform a daily backup or DISABLED if + daily backups are disabled. +
++ A target GMT hour range in which to perform a daily backup + or DISABLED if daily backups are disabled. +
++ Daily backups are disabled. +
++ Daily backup target of 00:00–02:00 GMT. +
++ Daily backup target of 02:00–04:00 GMT. +
++ Daily backup target of 04:00–06:00 GMT. +
++ Daily backup target of 06:00–08:00 GMT. +
++ Daily backup target of 08:00–10:00 GMT. +
++ Daily backup target of 10:00–12:00 GMT. +
++ Daily backup target of 12:00–14:00 GMT. +
++ Daily backup target of 14:00–16:00 GMT. +
++ Daily backup target of 16:00–18:00 GMT. +
++ Daily backup target of 18:00–20:00 GMT. +
++ Daily backup target of 20:00–22:00 GMT. +
++ Daily backup target of 22:00–00:00 GMT. +
++ A target day of the week in which to perform a weekly backup + or DISABLED if daily backups are disabled. +
++ Weekly backups are disabled. +
++ A weekly backup target of Sunday. +
++ A weekly backup target of Monday. +
++ A weekly backup target of Tuesday. +
++ A weekly backup target of Wednesday. +
++ A weekly backup target of Thursday. +
++ A weekly backup target of Friday. +
++ A weekly backup target of Saturday. +
++ A weekly backup target of Sunday. +
++ This schema file defines common types used by multiple + entities and possibly spanning several types of requests. +
++ An integer between 0 and 100 that denotes the progress of an + operation. +
+
+ This schema file defines faults that may be raised by the
+ Cloud Servers API. These faults are derived from the CloudServersAPIFault. Most faults
+ extend this type without adding any additional attributes or
+ elements. The only exception is the OverLimitAPIFault which adds a
+ retryAfter attribute. Because all faults
+ extend a standard base type, it should be possible to capture
+ all API faults with a single catch statement.
+
+ Faults are associated with a default HTTP status code that + corresponds to the particular fault type. For example an <itemNotFound> element is associated + with the HTTP status code 404. Some elements, the <cloudServersFault> element for + example, may be associated with multiple status codes. It is + also possible for multiple fault elements to be associated + with the same default code. The examples below showcase the + default status codes for each element type. Note that these + default codes are not part of the formal schema. In practice, + however, an element type will likely be associated with its + corresponding default status code. +
++ A generic Cloud Servers API fault. +
++ The item or resource could not be found. +
++ The operation is not allowed because the corresponding + server is in a build state. +
++ There is not enough capacity to honor the request. +
++ The operation is not allowed because the corresponding + server is being re-sized or backed up. +
++ The re-size operation is not permitted. +
++ The API service is currently unavailable. +
++ Insufficient privileges to honor the request, perhaps an + authentication token needs to be obtained or renewed. +
++ The request is malformed. +
++ The Content Type of the request is not supported. +
++ The HTTP method (or verb) is not + supported by the corresponding resource. +
++ The operation is currently not implemented. +
++ A human readable message that is appropriate for display + to the end user. +
++ The optional <details> element may contain useful + information for tracking down errors (e.g a stack + trace). This information may or may not be appropriate + for display to an end user. +
++ The HTTP status code associated with the current fault. +
++ An optional dateTime denoting when an operation should + be retried. +
++ This schema file defines all entities related to Flavors. +
++ The element defines an available hardware configuration for + a server. +
++ A collection of flavors. +
++ The ID of the flavor. +
++ The name of the flavor. +
++ The amount of RAM in the flavor in megabytes. +
++ The amount of disk space in the flavor in gigabytes. +
++ A collection of flavors. +
++ This schema file defines all entity related to Images. +
++ Common types used by multiple entities and possibly spanning + several types of requests. +
++ The element defines a collection of files used to create or + rebuild a server. +
++ A collection of images. +
++ The ID of the image. +
++ The name of the image. +
++ An optional ID of the server associated with the image. +
++ A time-stamp identifying the modification time of the + image. +
++ A creation time-stamp for the image. +
++ The progress of the current image operation. +
++ The current state (or status) of the + image. +
++ A collection of images. +
++ The image is in an unknown state. +
++ All operations have completed successfully, the image is + available for install. +
++ The image is being created (or saved). +
++ The image is being prepared to perform an operation. +
++ A request to perform an operation on the specified image + has been received. The operation is pending. +
++ The requested operation has failed. +
++ This schema file defines all entities related to Shared IP Groups. +
++ The element defines a group of servers that can share one or + more public IPs with each other. +
++ A collection of shared IP groups. +
++ An IP group type can take two basic forms. On a request + a single, optional, server ID may be specified… +
++ …on a response a server ID list is always returned. This + server list may be empty… +
++ …note that is a mutually exclusive choice: either + a <server> or <servers> element must be + specified, but not both. +
++ A single, optional, server ID. This form is used when + creating an IP group. +
++ A collection of server IDs. This form is used when + querying an IP group. +
++ The ID of the shared IP group. The attribute should not + be specified when creating a new shared IP group. +
++ The name of the shared IP group. +
++ A collection of shared IP groups. +
++ A collection of servers within a shared IP group. +
++ The ID of a server within a shared IP group. +
++ This schema file defines types related to preconfigured + limits. Limits are used to manage the capacity of the API and + to prevent abuse. The API defines two kinds of limits RateLimits and AbsoluteLimits. RateLimits are thresholds + that are reset after a certain amount of time passes. + Absolute limits are fixed. +
++ The limits element contains information on both rate and + absolute limits. +
++ A container that holds a list of rate limits, followed by a + list of absolute limits. +
++ The element hold a list of RateLimits. +
++ The element hold a list of AbsoluteLimits. +
++ A sequence of RateLimit elements. +
++ A sequence of AbsoluteLimit elements. +
++ A rate limit is a threshold that is reset after a certain + amount of time. Rate limits are imposed on the HTTP protocol + and they are based on an HTTPVerb and a regular expression + applied to a URI. For example, the rate limit below… +
++ …indicates that only 25 posts per day are allowed on + any API URI ending in /servers. The 26 post will raise an OverLimitFault until the resetTime arrives. +
++ It is important to note that rate limits should be applied in + order relative to the verb, going from least to most specific. + Thus, although the threshold for POST to */servers, below, is + 25 per day, one cannot POST to */servers more than 10 times + withing a single minute because the rate limits for any POST + is 10/min. +
++ The HTTPVerb the limit applies to. +
++ A human readable wild-card URI. Here "*" matches any + character. +
+
+ A machine processable regular expression URI. The regular
+ expression boundary matcher "^" takes affect after the root
+ URI path. For example, the regular expression ^/servers would
+ match the bold portion of the following URI:
+ https://servers.api.rackspacecloud.com/v1.0/3542812/servers
+
+ The unit of time (RateLimitUnit) associated + with the rate value. +
++ The rate limit in RateLimitUnits. +
++ The number of units remaining before an OverLimitFault is raised. +
++ The time in Unix time (the number of seconds since January + 1, 1970 00:00:00 UTC) when the rate limit will reset. +
++ Absolute limits are predefined fixed limits. We define each + of these limits as a key/value pair. Please consult the API Specification for a list of + absolute limits used by the system. +
++ The name (or key) of the absolute limit. Currently, + the following names are available: +
++ This may not be an exhaustive list. Please consult the API + Specification. We do not define absolute limit names as an + enumeration in this schema because we may need to impose new + limits quickly without the need to modifying the schema + document. +
++ A value specifying the absolute limit.The name of the + absolute limit determines the unit type. For example, the + key maxIPGroups implies that the value is in terms of + IPGroups. +
++ The HTTP verbs (or methods) on which rate-limits may be + enforced. +
++ Units of time supported by rate limits. +
++ This schema file defines a + Server and all internal entities + related to servers including: + Addresses, + ShareIPs, + Files, and + MetaData. +
++ Common types used by multiple entities and possibly spanning + several types of requests. +
++ The element defines a server. +
++ A collection of servers. +
++ The element defines list of addresses (public and private). +
++ The element defines a list of public addresses. +
++ The element defines list of private addresses. +
++ The element defines request to share a public IP address. +
++ The element defines request to add an IP address. +
++ The element defines response that returns an added IP address. +
++ A server is a virtual machine instance in the Cloud Servers + system. Note that this complex type defines all elements + and attributes as optional because a server instance may + take many different forms depending on the operation. When + creating a server, for example, the name, imageId, and + flavorId attributes are required. In addition, optional + metadata and personality file elements may be specified: +
++ The response to such a crate operation will include the + administration password, host ID, and addresses associated + with the server: +
++ When modifying a server only the name and administration + password should be specified as these are the only + attributes that are modifiable. +
++ A collection of meta data items associated with the server. +
++ A server's public and private address. +
++ A collection of small files used to personalize a new + server instance. +
++ The name of the server. +
++ The ID of the server. +
++ The server's administration password. +
++ The ID of the image used to create the server. +
++ The current server flavor ID. +
++ A unique ID that identifies the physical host that the VM + is running on. This ID is unique per + account and not globally unique. +
++ The progress of the current server operation. +
++ The current state (or status) of the + server. +
++ An ID of the shared IP + group that the server belongs to. +
++ A collection of servers. +
++ A collection of metadata items. +
++ A MetadataItem is simply a name-value pair. The name is + specified in the key attribute and the value is included inline. +
++ A meta data name-value pair. +
++ A collection of files. +
++ A file is simply a full path along with base64 file + content. The name of the file is specified in the path + attribute and the file content is included + inline. +
++ Full file path. +
++ Public server addresses. +
++ Private server addresses. +
++ A collection of addresses. +
++ An IP address. +
++ This type is used to represent a request to share an IP + address. +
++ The shared IP group use to + share the address. +
++ If true, the server is configured with the new address + though the address may not be enabled. +
++ This type is used to represent a request to add an IP + address. +
++ If true, the server is added and configured with the new address + though the address may not be enabled. +
++ The server is ready to use. +
++ The server is in an inactive (suspended) state. +
++ The server has been deleted. +
++ A request to perform a resize action has been received. The + operation is pending. +
++ The server is being prepared to perform the resize + operation. +
++ The server is being resized. +
++ The server is waiting for the resize operation to be + confirmed so that the original server may be removed. +
++ The server is in rescue mode. +
++ The requested operation failed, the server is in an + error state. +
++ The server is being built. +
++ The server is being restored. +
++ The server password is being changed. +
++ The server is being rebuilt. +
++ A shared IP address is being removed. +
++ An IP address is being shared, but not configured. +
++ An IP address is being shared, and the server is being + configured with the new address. +
++ An IP address is being added, but not configured. +
++ An IP address is being added, and the server is being + configured with the new address. +
++ The server is going through a SOFT reboot. +
++ The server is going through a HARD reboot. +
++ The server is in an unknown state. +
++ Reserved for future use. +
++ Reserved for future use. +
++ Reserved for future use. +
++ Reserved for future use. +
++ Reserved for future use. +
++ This schema file defines a version element which provides + meta information about the current version of the API Service. +
++ This element provides detailed meta information regarding the + status of the API version. Included is a pointer to both a + human readable and a machine processable description of the + API service. The machine processable description is written + in the Web Application Description Language (WADL). If a + discrepancy exists between the two specifications, the WADL is + authoritative as it contains the most accurate and up-to-date + description of the API service. +
++ A unique ID which identifies the API version. Currently + this is fixed as v1.0. The first element + of the path to the API endpoints always contains the + target version ID. +
++ The status of the API version. A stable version will + always have the value CURRENT. See VersionStatus. +
++ A URL to a human readable API specification in PDF + format. This URL will always point to the latest version + of the specification applicable to the requested + implementation. +
++ A URL to a machine readable API specification in WADL + format. This URL will always point to the latest version + of the specification applicable to the requested + implementation. +
++ A status of BETA indicates that this version is a + candidate for the next major release and may feature + functionality not available in the current version. + Developers are encouraged to test and begin the migration + processes to a BETA version. Note that a BETA version is + undergoing testing, it has not been officially released, + and my not be stable. +
++ The API version is stable and has been tested. Developers + are encouraged to develop against this API version. The + current released version of the API will always be marked + as CURRENT. +
++ A status of DEPRECATED indicates that a newer version of + the API is available. Application developers are + discouraged from using this version and should instead + develop against the latest current version of the API. +
+Loading...+
+ Your browser does not seem to have support for + namespace nodes in XPath. If you're a Firefox + user, please consider voting to get this issue + resolved: + + https://bugzilla.mozilla.org/show_bug.cgi?id=94270 + +
+|
+ |
+
+
+
+
+
+
+
+ |
+
|
+
+
+
+
+
+
+ |
+
| enum values | +|
| + |
+ A list of supported extensions. +
++ A detailed server list. +
++ A list of servers. Each server contains IDs, names, and + links -- other attributes are omitted. +
++ A list of addresses associated with a server. +
++ A list of addresses associated with a network. +
++ A detailed image list. +
++ A list of images. Each image contains IDs, names, and + links -- other attributes are omitted. +
++ A detailed flavor list. +
++ A list of flavors. Each flavor contains IDs, names, and + links -- other attributes are omitted. +
++ Metadata resource type, this is used for images and + servers. +
++ A List of Metadata +
++ Returns detailed information about this specific + version of the API. +
++ Returns current limits for the account. +
++ List all available extensions. +
++ Get details about a specific extension. +
++ List available images (all details). +
++ List available images (IDs, names, links). +
++ List details of the specified image. +
++ Deletes the specified image. +
++ Creates a new server. +
++ List all servers (IDs, names, links). +
++ List all servers (all details). +
++ List details of the specified server. +
++ Update the specified server's name and/or + administrative password. +
++ Terminate the specified server. +
++ Change a server's password. +
++ Reboot the specified server. +
++ Rebuild the specified server. +
++ Resize the specified server. +
++ Confirm a pending resize action. +
++ Cancel and revert a pending resize action. +
++ Creates a new image. +
++ List all server addresses. +
++ List addresses by Network ID. +
++ List available flavors (IDs, names, links). +
++ List available flavors (all detials). +
++ List details for the specified flavor. +
++ List metadata associated with the resoruce. +
++ Update metadata items. +
++ Set metadata. +
++ Get a metadata item associated with a resource. +
++ Set metadata item. +
++ Delete a metadata item. +
+Content-Type header
+ and is required for operations that have a request
+ body. The response format can be specified in
+ requests using either the Accept header
+ or adding an .xml or .json extension to the request
+ URI. Note that it is possible for a response to be
+ serialized using a format different from the request
+ (see example below). If no response format is
+ specified, JSON is the default. If conflicting
+ formats are specified using both an
+ Accept header and a query extension, the
+ query extension takes precedence.
+ | Format | +Accept Header | +Query Extension | +Default | +
| JSON | +application/json | +.json | +Yes | +
| XML | +application/xml | +.xml | +No | +
Accept
+ header. An alternative method of achieving the same
+ result is illustrated below – this time we utilize a
+ URI extension instead of an Accept
+ header.
+ self link contains a
+ versioned link to the resource. These links should be
+ used in cases where the link will be followed
+ immediately. A bookmark link provides a
+ permanent link to a resource that is appropriate for
+ long term storage. An alternate link can
+ contain an alternate representation of the resource.
+ For example, an OpenStack Compute image may have an
+ alternate representation in the OpenStack Image
+ service. Note that the type attribute here is used to
+ provide a hint as to the type of representation to
+ expect when following the link.
+ links. The
+ combination of the objects and arrays that start with
+ the name of the collection and an underscore
+ represent the collection in JSON. The approach allows
+ for extensibility of paginated collections by allowing
+ them to be associated with arbitrary properties. It
+ also allows collections to be embedded in other
+ objects as illustrated below. Here, a subset of
+ metadata items are presented within the image. Clients
+ must follow the "next" link to retrieve the full set
+ of metadata.
+ DELETED status that
+ indicates that the resource has been
+ removed. Implementations are not required to keep
+ track of deleted resources indefinitely, so sending a
+ changes since time in the distant past may miss
+ deletions.
+ | Verb | +URI | +RegEx | +Default | +||
| &POST; | +* | +.* | +10/min | +||
| &POST; | +*/servers | +^/servers | +50/day | +||
| &PUT; | +* | +.* | +10/min | +||
| &GET; | +*changes-since* | +changes-since | +3/min | +||
| &DELETE; | +* | +.* | +100/min | +||
Retry-After header to
+ notify the client when they can attempt to try
+ again.
+ | Name | +Value | +Description | +|||
| maxTotalRAMSize | +51200 | +Maximum total amount of + RAM (MB) | +|||
| maxServerMeta | +5 | +Maximum number of metadata items associated with a server | +|||
| maxImageMeta | +5 | +Maximum number of metadata items associated with an Image | +|||
| maxPersonality | +5 | +The maximum number of + file path/content pairs that can be + supplied on server build | +|||
| maxPersonalitySize | +10240 | +The maximum size, in + bytes, for each personality file | +|||
Accept
+ or Content-Type headers contains a MIME
+ type that identifies the version
+ (application/vnd.openstack.compute+xml;version=1.1). A
+ version MIME type is always linked to a base MIME type
+ (application/xml or application/json). If conflicting
+ versions are specified using both an HTTP header and a
+ URI, the URI takes precedence.
+ DEPRECATED. Providers should work with
+ developers and partners to ensure there is adequate
+ time to migrate to the new version before deprecated
+ versions are discontinued.
+ Accept
+ header containing application/atom+xml or by adding a
+ .atom to the request URI. This allows standard Atom
+ clients to track version changes.
+ RS-CBS
+ namespace. Actions work in exactly the same manner as
+ illustrated in X- followed by the alias and a dash:
+ (X-RS-CBS-HEADER1). States and
+ parameters must be prefixed with the extension alias
+ followed by a colon. For example, an image may be in
+ the RS-PIE:PrepareShare state.
+ UNKNOWN state if the application does
+ not support the extension. Applications should
+ also verify that an extension is available before
+ submitting an extended request.
+ | Fault Element | +Associated Error Codes | +Expected in All Requests? | +
| computeFault | +500, 400, other codes possible | +&CHECK; | +
| serviceUnavailable | +503 | +&CHECK; | +
| unauthorized | +401 | +&CHECK; | +
| forbidden | +403 | +&CHECK; | +
| badRequest | +400 | +&CHECK; | +
| overLimit | +413 | +&CHECK; | +
| badMediaType | +415 | ++ |
| badMethod | +405 | ++ |
| itemNotFound | +404 | ++ |
| buildInProgress | +409 | ++ |
| serverCapacityUnavailable | +503 | ++ |
| backupOrResizeInProgress | +409 | ++ |
| resizeNotAllowed | +403 | ++ |
| notImplemented | +501 | ++ |
ERROR
+ state and the fault is embedded in the offending
+ server or image. Note that these asynchronous
+ faults follow the same format as the synchronous
+ ones. The fault contains an error code, a human
+ readable message, and optional details about the
+ error. Additionally, asynchronous faults may also
+ contain a created timestamp that specify when the
+ fault occured.
+ ACTIVE status are
+ available for use. Other possible values for the
+ status attribute include: BUILD,
+ REBUILD, SUSPENDED,
+ RESIZE, VERIFY_RESIZE,
+ PASSWORD, REBOOT,
+ HARD_REBOOT, DELETED,
+ UNKNOWN, and ERROR.
+ BUILD &ARROW; ACTIVE
+ BUILD &ARROW; ERROR (on error)
+ Location header and
+ is available as a self and
+ bookmark link in the server
+ representation (See ERROR state if the complexity
+ requirements are not met. In this case, an
+ client may issue a change password action to
+ reset the server password (see -r--r----- ).
+ ACTIVE &ARROW;
+ ACTIVE
+ ACTIVE &ARROW;
+ DELETED
+ ERROR &ARROW;
+ DELETED
+ ACTIVE &ARROW;
+ PASSWORD &ARROW;
+ ACTIVE
+ ACTIVE &ARROW;
+ PASSWORD &ARROW;
+ ERROR (on error)
+ ERROR &ARROW;
+ PASSWORD &ARROW;
+ ACTIVE (password reset
+ after error)
+ ERROR state if the complexity
+ requirements are not met. In this case, a client
+ may reissue the change password action.
+ ACTIVE &ARROW;
+ REBOOT &ARROW;
+ ACTIVE (ACTIVE &ARROW;
+ HARD_REBOOT &ARROW;
+ ACTIVE (SOFT), the operating system is signaled to
+ restart, which allows for a graceful shutdown of
+ all processes. A hard reboot (HARD) is the
+ equivalent of power cycling the server.
+ ACTIVE &ARROW;
+ REBUILD &ARROW;
+ ACTIVE
+ ACTIVE &ARROW;
+ REBUILD &ARROW;
+ ERROR (on error)
+ Location header.
+ ACTIVE &ARROW;
+ RESIZE &ARROW;
+ VERIFY_RESIZE
+ ACTIVE &ARROW;
+ RESIZE &ARROW;
+ ACTIVE (on error)
+ VERIFY_RESIZE &ARROW;
+ ACTIVE
+ VERIFY_RESIZE &ARROW;
+ ERROR (on error)
+ VERIFY_RESIZE &ARROW;
+ ACTIVE
+ VERIFY_RESIZE &ARROW;
+ ERROR (on error)
+ SAVING &ARROW; ACTIVE
+ SAVING &ARROW; ERROR (on error)
+ Location header,
+ additional attributes for the image including
+ creation status may be retrieved by performing a
+ subsequent &GET; on that URL. See SAVING and the conditional
+ progress element (0-100% completion) will also be
+ returned. Other possible values for the status
+ attribute include: UNKNOWN,
+ ACTIVE, SAVING,
+ ERROR, and
+ DELETED. Images with an
+ ACTIVE status are available for
+ install. The optional minDisk and minRam
+ attributes set the minimum disk and RAM
+ requirements needed to create a server with the
+ image.
+ ACTIVE &ARROW; DELETED
+ ERROR &ARROW; DELETED
+ + This schema file defines actions that can be performed on a + cloud server. All cloud server actions are derived from the Action type. +
++ Types related to servers. +
++ Performs a HARD or SOFT reboot. +
++ Rebuilds a server. +
++ Resizes a server. +
++ Confirms a resize action. +
++ Reverts a resize action. +
++ Changes a server's password. +
++ The action creates a new image for the server. +
++ This is the base type for all server actions. It is simply + a marker abstract type used to differentiate an Action + element from other elements. +
++ The type of reboot to perform. +
++ A collection of meta data items + associated with the server. If not + specified the original server metadata + will be kept. +
++ A collection of small files used to personalize a + new server instance. Exisiting server + personality files are deleted by the + rebuild process. +
++ The name of the server. If not specified the + original server name will be kept. +
++ The server's administration password. +
++ A reference to an image to use for the + rebuild. A local image need contain only an + Image ID. External images must contian a + link that provides the full path to the + image resource. You must supply an image + when rebuilding. +
++ A reference to the flavor to convert to. +
++ The server's administration password. +
++ A collection of meta data items + associated with the image. +
++ The name of the image to create. +
++ A HARD reboot is equivalent to power cycling the server. + The operating system is not allowed to gracefully + shutdown. +
++ With a SOFT reboot, the operating system is signaled to + restart. This allows for a graceful shutdown of all + processes. +
++ This is the main index XML Schema document + for Common API Schema Types Version 1.0. +
++ Types related to extensions. +
++ Types related to rate and absolute limits. +
++ Types related to API version details. +
++ This is the main index XML Schema document + for the Open Stack Compute API Version 1.1. +
++ Servers and all internal Entities including Addresses and + Files. +
++ Types related to images. +
++ Types related to flavors. +
++ Defines server actions: reboot, rebuild, resize... +
++ Metadata for Server and Image. +
++ All fault types. +
++ This schema file simple defines an atom link according + to RFC4287 +
++ This schema document describes the XML namespace, in a form + suitable for import by other schema documents. +
++ See + http://www.w3.org/XML/1998/namespace.html and + + http://www.w3.org/TR/REC-xml for information + about this namespace. +
++ Note that local names in this namespace are intended to be + defined only by the World Wide Web Consortium or its subgroups. + The names currently defined in this namespace are listed below. + They should not be used with conflicting semantics by any Working + Group, specification, or document instance. +
++ See further below in this document for more information about how to refer to this schema document from your own + XSD schema documents and about the + namespace-versioning policy governing this schema document. +
++ denotes an attribute whose value + is a language code for the natural language of the content of + any element; its value is inherited. This name is reserved + by virtue of its definition in the XML specification.
+ ++ Attempting to install the relevant ISO 2- and 3-letter + codes as the enumerated possible values is probably never + going to be a realistic possibility. +
++ See BCP 47 at + http://www.rfc-editor.org/rfc/bcp/bcp47.txt + and the IANA language subtag registry at + + http://www.iana.org/assignments/language-subtag-registry + for further information. +
++ The union allows for the 'un-declaration' of xml:lang with + the empty string. +
++ denotes an attribute whose + value is a keyword indicating what whitespace processing + discipline is intended for the content of the element; its + value is inherited. This name is reserved by virtue of its + definition in the XML specification.
+ ++ denotes an attribute whose value + provides a URI to be used as the base for interpreting any + relative URIs in the scope of the element on which it + appears; its value is inherited. This name is reserved + by virtue of its definition in the XML Base specification.
+ ++ See http://www.w3.org/TR/xmlbase/ + for information about this attribute. +
++ denotes an attribute whose value + should be interpreted as if declared to be of type ID. + This name is reserved by virtue of its definition in the + xml:id specification.
+ ++ See http://www.w3.org/TR/xml-id/ + for information about this attribute. +
++ denotes Jon Bosak, the chair of + the original XML Working Group. This name is reserved by + the following decision of the W3C XML Plenary and + XML Coordination groups: +
++++ In appreciation for his vision, leadership and + dedication the W3C XML Plenary on this 10th day of + February, 2000, reserves for Jon Bosak in perpetuity + the XML name "xml:Father". +
+
+ This schema defines attributes and an attribute group suitable
+ for use by schemas wishing to allow xml:base,
+ xml:lang, xml:space or
+ xml:id attributes on elements they define.
+
+ To enable this, such a schema must import this schema for + the XML namespace, e.g. as follows: +
++ <schema . . .> + . . . + <import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> ++
+ or +
++ <import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2009/01/xml.xsd"/> ++
+ Subsequently, qualified reference to any of the attributes or the + group defined below will have the desired effect, e.g. +
++ <type . . .> + . . . + <attributeGroup ref="xml:specialAttrs"/> ++
+ will define a type which will schema-validate an instance element + with any of those attributes. +
++ In keeping with the XML Schema WG's standard versioning + policy, this schema document will persist at + + http://www.w3.org/2009/01/xml.xsd. +
++ At the date of issue it can also be found at + + http://www.w3.org/2001/xml.xsd. +
++ The schema document at that URI may however change in the future, + in order to remain compatible with the latest version of XML + Schema itself, or with the XML namespace itself. In other words, + if the XML Schema or XML namespaces change, the version of this + document at + http://www.w3.org/2001/xml.xsd + + will change accordingly; the version at + + http://www.w3.org/2009/01/xml.xsd + + will not change. +
++ Previous dated (and unchanging) versions of this schema + document are at: +
+ ++ This schema file defines all entities related to Backup Schedules. +
++ This element is used to create periodic daily and weekly + images automatically. +
++ If true, both daily and weekly backup schedules are + disabled. +
++ A WeeklyBackup type that describes the day + of the week in which to perform a weekly backup or + DISABLED if weekly backups are disabled. +
++ A DailyBackup type that describes an hour + range in which to perform a daily backup or DISABLED if + daily backups are disabled. +
++ A target GMT hour range in which to perform a daily backup + or DISABLED if daily backups are disabled. +
++ Daily backups are disabled. +
++ Daily backup target of 00:00–02:00 GMT. +
++ Daily backup target of 02:00–04:00 GMT. +
++ Daily backup target of 04:00–06:00 GMT. +
++ Daily backup target of 06:00–08:00 GMT. +
++ Daily backup target of 08:00–10:00 GMT. +
++ Daily backup target of 10:00–12:00 GMT. +
++ Daily backup target of 12:00–14:00 GMT. +
++ Daily backup target of 14:00–16:00 GMT. +
++ Daily backup target of 16:00–18:00 GMT. +
++ Daily backup target of 18:00–20:00 GMT. +
++ Daily backup target of 20:00–22:00 GMT. +
++ Daily backup target of 22:00–00:00 GMT. +
++ A target day of the week in which to perform a weekly backup + or DISABLED if daily backups are disabled. +
++ Weekly backups are disabled. +
++ A weekly backup target of Sunday. +
++ A weekly backup target of Monday. +
++ A weekly backup target of Tuesday. +
++ A weekly backup target of Wednesday. +
++ A weekly backup target of Thursday. +
++ A weekly backup target of Friday. +
++ A weekly backup target of Saturday. +
++ A weekly backup target of Sunday. +
++ This schema file defines common types used by multiple + entities and possibly spanning several types of requests. +
++ A collection of metadata items. There may be an + absolute limit that imposes additional constraints on + the number of metadata items. +
++ A MetadataItem is simply a name-value pair. The name is + specified in the key attribute and the value is included inline. +
++ A meta data name-value pair. +
++ An integer between 0 and 100 that denotes the progress of an + operation. +
++ A universally unique identifier. +
++ An extended status must contian a prefix. +
++ A flag that identifies whether a disk is auto + managed or manual managed. The attribute can only + be applied to an Image. +
++ This schema file defines types related to API + extensions. +
++ A list of supported extensions. +
++ Detials about a specific extension. +
++ A list of extensions. +
++ Detials about a specific extension. +
++ A short description of what the extension + does. +
++ A human reabable extension name. +
++ Extension namespace used for XML representations. +
++ A vendor prefix alieas used for non-XML + representations. +
++ The time that the extension was added or + modifided. +
++ There should be at least one atom link with a + describedby relation. This relation provides + developer info for the extension. +
+
+ Vendor aliases are used to differentiate
+ extensions in non-XML representations as well as
+ in HTTP headers and in the URL path. An alias is
+ made of a vendor prefix, followed be a a dash (-)
+ followed be a short extension ID. For example:
+ RAX-PIE.
+
+ This schema file defines faults that may be raised by the
+ OpenStack Compute API. These faults are derived from the ComputeAPIFault. Most faults extend this
+ type without adding any additional attributes or elements.
+ The only exceptions is the OverLimitAPIFault which adds a
+ retryAt attribute and the AsyncAPIFault which adds a
+ created timestamp. Because all faults extend
+ a standard base type, it should be possible to capture all API
+ faults with a single catch statement.
+
+ Faults are associated with a default HTTP status code that + corresponds to the particular fault type. For example an <itemNotFound> element is associated + with the HTTP status code 404. Some elements, the <computeFault> element for + example, may be associated with multiple status codes. It is + also possible for multiple fault elements to be associated + with the same default code. The examples below showcase the + default status codes for each element type. Note that these + default codes are not part of the formal schema. In practice, + however, an element type will likely be associated with its + corresponding default status code. +
++ A generic Cloud Servers API fault. +
++ The item or resource could not be found. +
++ The operation is not allowed because the corresponding + server is in a build state. +
++ There is not enough capacity to honor the request. +
++ The operation is not allowed because the corresponding + server is being re-sized or backed up. +
++ The re-size operation is not permitted. +
++ The API service is currently unavailable. +
++ Insufficient privileges to honor the request, perhaps an + authentication token needs to be obtained or renewed. +
++ Authentication has been validated, however the operation is unauthorized. +
++ The request is malformed. +
++ The Content Type of the request is not supported. +
++ The HTTP method (or verb) is not + supported by the corresponding resource. +
++ The operation is currently not implemented. +
++ A human readable message that is appropriate for display + to the end user. +
++ The optional <details> element may contain useful + information for tracking down errors (e.g a stack + trace). This information may or may not be appropriate + for display to an end user. +
++ The HTTP status code associated with the current fault. +
++ An optional dateTime denoting when an operation should + be retried. +
++ An optional dateTime denoting when the fault + was created. +
++ This schema file defines all entities related to Flavors. +
++ Common types used by multiple entities and possibly spanning + several types of requests. +
++ The element defines an available hardware configuration for + a server. +
++ A collection of flavors. +
++ The ID of the flavor. +
++ The name of the flavor. +
++ The amount of RAM in the flavor in megabytes. +
++ The amount of disk space in the flavor in gigabytes. +
++ The amount of cores allocated. +
++ The only allowed attributes for this Flavor type is + the name, ID, and links. This type is used for + non-detailed list of flavors. +
++ Here the flavor MUST + contain a name, an ID, a bookmark link, + and a self link. +
++ A collection of flavors. +
++ A collection of flavors with ID, names, and links + only. This type is used for non-detailed list of + flavors. +
++ This schema file defines all entity related to Images. +
++ Common types used by multiple entities and possibly spanning + several types of requests. +
++ Servers and all internal Entities including: Addresses, + and Files. +
++ All fault types. +
++ The element defines a collection of files used to create or + rebuild a server. +
++ A collection of images. +
++ The server associated with the image. This may + not contain full server details but will + always contain an ID, a name, as well as self + and bookmark links. +
++ A collection of meta data items associated with the image. +
++ The details of a fault that may have occurred + while creating an image. +
++ The ID of the image. +
++ The name of the image. +
++ A unique ID that identifies the tenant that contains + the image. +
++ A unique ID that identifies the user who created + the image. +
++ A time-stamp identifying the modification time of the + image. +
++ A creation time-stamp for the image. +
++ The progress of the current image operation. +
++ The current state (or status) of the + image. +
++ Minimum disk space required for the image in gigabytes. +
++ The minimum amount of RAM required for the image in + megabytes. +
++ The only allowed attribute for this Image type is + the name, ID, and links. This is used for + non-detailed list of images. +
++ Here the image MUST + contain a name, an ID, a bookmark link, + and a self link. +
++ A collection of images (all details). +
++ A collection of images with only IDs, names, and + links. This is used for the non-detailed list of + images. +
++ An extensible image status type allows all of the + strings defined in ImageStatus or an + alias prefixed status. +
++ The image is in an unknown state. +
++ All operations have completed successfully, the image is + available for install. +
++ The image is being created (or saved). +
++ The image has been deleted. +
++ The requested operation has failed. +
++ This schema file defines all entities related to Shared IP Groups. +
++ Common types used by multiple entities and possibly spanning + several types of requests. +
++ The element defines a group of servers that can share one or + more public IPs with each other. +
++ A collection of shared IP groups. +
++ An IP group type can take two basic forms. On a request + a single, optional, server ID may be specified… +
++ …on a response a server ID list is always returned. This + server list may be empty… +
++ …note that is a mutually exclusive choice: either + a <server> or <servers> element must be + specified, but not both. +
++ A single, optional, server ID. This form is used when + creating an IP group. +
++ A collection of server IDs. This form is used when + querying an IP group. +
++ The ID of the shared IP group. The attribute should not + be specified when creating a new shared IP group. +
++ The name of the shared IP group. +
++ A collection of shared IP groups. +
++ A collection of servers within a shared IP group. +
++ The ID of a server within a shared IP group. +
++ This schema file defines types related to + preconfigured limits. Limits are used to manage the + capacity of the API and to prevent abuse. The API + defines two kinds of limits RateLimits + and AbsoluteLimits. RateLimits are + thresholds that are reset after a certain amount of + time passes. Absolute limits are fixed. +
++ The limits element contains information on both rate and + absolute limits. +
++ This schema file defines metadata for servers and images. +
++ Common types used by multiple entities and possibly spanning + several types of requests. +
++ The element defines a Metadata. +
++ The element defines a metadata item. +
++ This schema file defines a Server and all internal + entities related to servers including Addresses and Files. +
++ Common types used by multiple entities and possibly spanning + several types of requests. +
++ Types related to images. +
++ Types related to flavors. +
++ All fault types. +
++ The element defines a server. +
++ A collection of servers. +
++ The element defines list of addresses by network: (public, + private, ...). +
++ The element defines a list of addresses in a network. +
++ The element defines an individual IP address. +
++ A server is a virtual machine instance in the Cloud Servers + system. Note that this complex type defines all elements + and attributes as optional because a server instance may + take many different forms depending on the operation. When + creating a server, for example, the name, imageRef, and + flavorRef attributes are required. In addition, optional + metadata and personality file elements may be specified: +
++ The response to such a crate operation will include the + administration password, host ID, and addresses associated + with the server: +
++ When modifying a server only the name and administration + password should be specified as these are the only + attributes that are modifiable. +
++ A reference to an image used to create the + server. External images must contian a link that + provides the full path to the image resource. +
++ The current server flavor. This may not contais + all flavor detials but will always contain an + ID, a name, as well as self and bookmark links. +
++ A collection of meta data items associated with the server. +
++ A server's public and private address. +
++ A collection of small files used to personalize a new + server instance. +
++ The detials of a fault that may have occured + while cerating the server or performing a server + action. +
++ The name of the server. +
++ A reference to an image. This is used exclusevely when + creating a server. Using an image ID here indicates that + the image is locally hosted. +
++ A reference to a flavor. This is used exclusevely when + creating a server. Using a flavorRef here indicates that + the flavor is locally hosted. +
++ The IPv4 primary IP. +
++ The IPv6 primary IP. +
++ The ID of the server. +
++ The server's administration password. +
++ A unique ID that identifies the tenant that contains + the server. +
++ A unique ID that identifies the user who created + the server. +
++ A unique ID that identifies the physical host that the VM + is running on. This ID is unique per + account and not globally unique. +
++ The progress of the current server operation. +
++ The current state (or status) of the + server. +
++ The time the server was updated. +
++ The time the server was created. +
++ The only allowed attribute for this Server type is + the name, ID, and links. This type is used for + non-detailed server lists. +
++ Here the server MUST + contain a name, an ID, a bookmark link, + and a self link. +
++ When creating a server the server must contain a + name and a reference to an image and flavor. +
++ A collection of meta data items associated with the server. +
++ A collection of small files used to personalize a new + server instance. +
++ When updating a server. The server + MUST contain either a + name or metadata or access address. The + other fields are not editabile on a + server update. +
++ A collection of servers. +
++ A collection of servers with only IDs, names, and + links. A collection of this type is returned in + non-detailed server list. +
++ A collection of files. +
++ A file is simply a full path along with base64 file + content. The name of the file is specified in the path + attribute and the file content is included + inline. +
++ Full file path. +
++ A collection of addresses. +
++ A id of an address list. This is typically a name + used to identify a network. +
++ An IP address. +
++ The IP Address version can be 4 or 6. The version + attribute is optional if it is left off, the type of + address will be determined by from its address + format. If it is specified it should + match the address format. +
++ The OpenStack compute API will always fill in the + version number as a convinence to the client. +
++ An extensible server status type allows all of the + strings defined in ServerStatus or an alias prefixed + status. +
++ The server is ready to use. +
++ The server is in an inactive (suspended) state. +
++ The server has been deleted. +
++ The server is being resized. +
++ The server is waiting for the resize operation to be + confirmed so that the original server may be removed. +
++ The requested operation failed, the server is in an + error state. +
++ The server is being built. +
++ The server password is being changed. +
++ The server is being rebuilt. +
++ The server is going through a SOFT reboot. +
++ The server is going through a HARD reboot. +
++ The server is in an unknown state. +
++ Denotes IPv4. +
++ Denotes IPv6. +
++ The element defines request to share a public IP address. +
++ This type is used to represent a request to share an IP + address. +
++ The + shared IP group + + use to + share the address. +
++ If true, the server is configured with the new address + though the address may not be enabled. +
++ This schema file defines all types related to versioning. +
++ This element is returned when the version of the + resource cannot be determined. The element + provides a list of choices for the resource. +
++ Provides a list of supported versions. +
++ This element provides detailed meta information + regarding the status of the current API version. + This is the XSD 1.0 compatible element definition. +
++ This element provides detailed meta information + regarding the status of the current API + version. The description should include a pointer + to both a human readable and a machine processable + description of the API service. +
+Loading...+
+ Your browser does not seem to have support for + namespace nodes in XPath. If you're a Firefox + user, please consider voting to get this issue + resolved: + + https://bugzilla.mozilla.org/show_bug.cgi?id=94270 + +
+|
+ |
+
+
+
+
+
+
+
+ |
+
|
+
+
+
+
+
+
+ |
+
| enum values | +|
| + |