summaryrefslogtreecommitdiff
path: root/api-guide
diff options
context:
space:
mode:
authorjichenjc <jichenjc@cn.ibm.com>2015-12-18 11:17:29 +0800
committerjichenjc <jichenjc@cn.ibm.com>2016-01-22 00:14:46 +0800
commit040577c0cf79239dfe712154eb21eda8f808d0c2 (patch)
tree47c543efe37769b06fbb2d03cfb7e612c1fd9640 /api-guide
parent2c59e613c04ca373e298972f421749def5d4236e (diff)
downloadnova-040577c0cf79239dfe712154eb21eda8f808d0c2.tar.gz
Add description for server query
Add descriptions for server query options and add some samples for the query options. Implement blueprint complete-todo-in-api-concept-doc Change-Id: Id23a19ecc30f1837f4755ec898ef0389dcf23a8f
Diffstat (limited to 'api-guide')
-rw-r--r--api-guide/source/server_concepts.rst256
1 files changed, 254 insertions, 2 deletions
diff --git a/api-guide/source/server_concepts.rst b/api-guide/source/server_concepts.rst
index a2317f50bc..4bdf24d3f5 100644
--- a/api-guide/source/server_concepts.rst
+++ b/api-guide/source/server_concepts.rst
@@ -125,8 +125,260 @@ operations on the server.
Server query
~~~~~~~~~~~~
-TODO: We should introduce that there are multiple methods to filter the
-response of list servers.
+Nova allows both general user and administrator to filter the server
+query result by using query options.
+
+For general user, ``reservation_id``, ``name``, ``status``, ``image``,
+``flavor``, ``ip``, ``changes-since``, ``all_tenants``,
+``ip6 (microversion 2.5)`` are supported options to be used. The other
+options will be ignored by nova silently only with a debug log.
+
+For administrator, there are more fields can be used.
+Usually the filter is operated on the database schema definition of
+``class Instance``, e.g there is a field named 'locked' in the schema
+then the filter can use 'locked' as search options to filter servers.
+Also, there are some special options such as ``changes-since`` can
+be used and interpreted by nova.
+
+- **General user & Administrator supported options**
+ General user supported options are listed above and administrator can
+ use almost all the options except the options parameters for sorting
+ and pagination.
+
+.. code::
+ Precondition:
+ there are 2 servers existing in cloud with following info:
+
+ "servers":[
+ {
+ "name": "t1",
+ "locked": "true",
+ ...
+ }
+ {
+ "name":"t2",
+ "locked": "false",
+ ...
+ }
+
+ **Example: General user query server with administrator only options**
+
+.. code::
+ Request with non-administrator context:
+ GET /servers/detail?locked=1
+ Note that 'locked' is not returned through API layer
+
+ Response:
+ {
+ "servers":[
+ {
+ "name": "t1",
+ ...
+ }
+ {
+ "name":"t2",
+ ...
+ }
+ ]
+ }
+
+ **Example: Administrator query server with administrator only options**
+
+.. code::
+ Request with administrator context:
+ GET /servers/detail?locked=1
+
+ Response:
+ {
+ "servers":[
+ {
+ "name": "t1",
+ ...
+ }
+ ]
+ }
+
+- **Exact matching and regex matching of the search options**
+
+ Depending on the name of a filter, matching for that filter is performed
+ using either exact matching or as regular expression matching.
+ ``project_id``, ``user_id``, ``image_ref``, ``vm_state``,
+ ``instance_type_id``, ``uuid``, ``metadata``, ``host``, ``system_metadata``
+ are the options that are applied by exact matching when filtering.
+
+ **Example: User query server using exact matching on host**
+
+.. code::
+ Precondition:
+ Request with administrator context:
+ GET /servers/detail
+
+ Response:
+
+ {
+ "servers":[
+ {
+ "name": "t1",
+ "OS-EXT-SRV-ATTR:host": "devstack"
+ ...
+ }
+ {
+ "name": "t2",
+ "OS-EXT-SRV-ATTR:host": "devstack1"
+ ...
+ }
+ ]
+ }
+
+ Request with administrator context:
+ GET /servers/detail?host=devstack
+
+ Response:
+
+ {
+ "servers":[
+ {
+ "name": "t1",
+ "OS-EXT-SRV-ATTR:host": "devstack"
+ ...
+ }
+ ]
+ }
+
+ **Example: Query server using regex matching on name**
+
+.. code::
+ Precondition:
+ Request with administrator context:
+ GET /servers/detail
+
+ Response:
+
+ {
+ "servers":[
+ {
+ "name": "test11",
+ ...
+ }
+ {
+ "name": "test21",
+ ...
+ }
+ {
+ "name": "t1",
+ ...
+ }
+ {
+ "name": "t14",
+ ...
+ }
+ ]
+ }
+
+ Request with administrator context:
+ GET /servers/detail?name=t1
+
+ Response:
+
+ {
+ "servers":[
+ {
+ "name": "test11",
+ ...
+ }
+ {
+ "name": "t1",
+ ...
+ }
+ {
+ "name": "t14",
+ ...
+ }
+ ]
+ }
+
+ **Example: User query server using exact matching on host and
+ regex matching on name**
+
+.. code::
+ Precondition:
+ Request with administrator context:
+ GET /servers/detail
+
+ Response:
+
+ {
+ "servers":[
+ {
+ "name": "test1",
+ "OS-EXT-SRV-ATTR:host": "devstack"
+ ...
+ }
+ {
+ "name": "t2",
+ "OS-EXT-SRV-ATTR:host": "devstack1"
+ ...
+ }
+ {
+ "name": "test3",
+ "OS-EXT-SRV-ATTR:host": "devstack1"
+ ...
+ }
+ ]
+ }
+
+ Request with administrator context:
+ GET /servers/detail?host=devstack1&name=test
+
+ Response:
+
+ {
+ "servers":[
+ {
+ "name": "test3",
+ "OS-EXT-SRV-ATTR:host": "devstack1"
+ ...
+ }
+ ]
+ }
+
+- **Speical keys are used to tweek the query**
+ ``changes-since`` returns instances updated after the given time,
+ ``deleted`` return (or exclude) deleted instances and ``soft_deleted``
+ modify behavior of 'deleted' to either include or exclude instances whose
+ vm_state is SOFT_DELETED. Please see: :doc:`polling_changes-since_parameter`
+
+ **Example: User query server with special keys changes-since**
+
+.. code::
+ Precondition:
+ GET /servers/detail
+
+ Response:
+ {
+ "servers":[
+ {
+ "name": "t1"
+ "updated": "2015-12-15T15:55:52Z"
+ ...
+ }
+ {
+ "name": "t2",
+ "updated": "2015-12-17T15:55:52Z"
+ ...
+ }
+ }
+
+ GET /servers/detail?changes-since='2015-12-16T15:55:52Z'
+
+ Response:
+ {
+ {
+ "name": "t2",
+ "updated": "2015-12-17T15:55:52Z"
+ ...
+ }
+ }
Server actions
~~~~~~~~~~~~~~~