1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
|
REST API Version History
========================
This documents the changes made to the REST API with every
microversion change. The description for each version should be a
verbose one which has enough information to be suitable for use in
user documentation.
2.1
---
This is the initial version of the v2.1 API which supports
microversions. The V2.1 API is from the REST API users's point of
view exactly the same as v2.0 except with strong input validation.
A user can specify a header in the API request::
X-OpenStack-Nova-API-Version: <version>
where ``<version>`` is any valid api version for this API.
If no version is specified then the API will behave as if a version
request of v2.1 was requested.
2.2
---
Added Keypair type.
A user can request the creation of a certain 'type' of keypair (``ssh`` or ``x509``)
in the ``os-keypairs`` plugin
If no keypair type is specified, then the default ``ssh`` type of keypair is
created.
Fixes status code for ``os-keypairs`` create method from 200 to 201
Fixes status code for ``os-keypairs`` delete method from 202 to 204
2.3 (Maximum in Kilo)
---------------------
Exposed additional attributes in ``os-extended-server-attributes``:
``reservation_id``, ``launch_index``, ``ramdisk_id``, ``kernel_id``, ``hostname``,
``root_device_name``, ``userdata``.
Exposed ``delete_on_termination`` for ``volumes_attached`` in ``os-extended-volumes``.
This change is required for the extraction of EC2 API into a standalone
service. It exposes necessary properties absent in public nova APIs yet.
Add info for Standalone EC2 API to cut access to Nova DB.
2.4
---
Show the ``reserved`` status on a ``FixedIP`` object in the ``os-fixed-ips`` API
extension. The extension allows one to ``reserve`` and ``unreserve`` a fixed IP
but the show method does not report the current status.
2.5
---
Before version 2.5, the command ``nova list --ip6 xxx`` returns all servers
for non-admins, as the filter option is silently discarded. There is no
reason to treat ip6 different from ip, though, so we just add this
option to the allowed list.
2.6
---
A new API for getting remote console is added::
POST /servers/<uuid>/remote-consoles
{
"remote_console": {
"protocol": ["vnc"|"rdp"|"serial"|"spice"],
"type": ["novnc"|"xpvnc"|"rdp-html5"|"spice-html5"|"serial"]
}
}
Example response::
{
"remote_console": {
"protocol": "vnc",
"type": "novnc",
"url": "http://example.com:6080/vnc_auto.html?token=XYZ"
}
}
The old APIs 'os-getVNCConsole', 'os-getSPICEConsole', 'os-getSerialConsole'
and 'os-getRDPConsole' are removed.
2.7
---
Check the ``is_public`` attribute of a flavor before adding tenant access
to it. Reject the request with HTTPConflict error.
2.8
---
Add 'mks' protocol and 'webmks' type for remote consoles.
2.9
---
Add a new ``locked`` attribute to the detailed view of
servers. ``locked`` will be ``true`` if anyone is currently holding
a lock on the server, ``false`` otherwise.
2.10
----
Added user_id parameter to os-keypairs plugin, as well as a new property
in the request body, for the create operation.
Administrators will be able to list, get details and delete keypairs owned by
users other than themselves and to create new keypairs on behalf of their
users.
2.11
----
Exposed attribute ``forced_down`` for ``os-services``.
Added ability to change the ``forced_down`` attribute by calling an update.
2.12 (Maximum in Liberty)
-------------------------
Exposes VIF ``net_id`` attribute in ``os-virtual-interfaces``.
User will be able to get Virtual Interfaces ``net_id`` in Virtual Interfaces
list and can determine in which network a Virtual Interface is plugged into.
2.13
----
Add information ``project_id`` and ``user_id`` to ``os-server-groups``
API response data.
2.14
----
Remove ``onSharedStorage`` parameter from server's evacuate action. Nova will
automatically detect if the instance is on shared storage.
Also adminPass is removed from the response body. The user can get the
password with the server's os-server-password action.
2.15
----
From this version of the API users can choose 'soft-affinity' and
'soft-anti-affinity' rules too for server-groups.
2.16
----
Exposes new host_status attribute for servers/detail and servers/{server_id}.
Ability to get nova-compute status when querying servers. By default, this is
only exposed to cloud administrators.
2.17
----
Add a new API for triggering crash dump in an instance. Different operation
systems in instance may need different configurations to trigger crash dump.
2.18
----
Establishes a set of routes that makes project_id an optional construct in v2.1.
2.19
----
Allow the user to set and get the server description.
The user will be able to set the description when creating, rebuilding,
or updating a server, and get the description as part of the server details.
2.20
----
From this version of the API user can call detach and attach volumes for
instances which are in shelved and shelved_offloaded state.
2.21
----
The ``os-instance-actions`` API now returns information from deleted
instances.
2.22
----
A new resource servers:migrations added. A new API to force live migration
to complete added::
POST /servers/<uuid>/migrations/<id>/action
{
"force_complete": null
}
2.23
----
From this version of the API users can get the migration summary list by
index API or the information of a specific migration by get API.
And the old top-level resource `/os-migrations` won't be extended anymore.
Add migration_type for old /os-migrations API, also add ref link to the
/servers/{uuid}/migrations/{id} for it when the migration is an in-progress
live-migration.
2.24
----
A new API call to cancel a running live migration::
DELETE /servers/<uuid>/migrations/<id>
2.25 (Maximum in Mitaka)
------------------------
Modify input parameter for ``os-migrateLive``. The block_migration will
support 'auto' value, and disk_over_commit flag will be removed.
2.26
----
Added support of server tags.
A user can create, update, delete or check existence of simple string tags
for servers by the os-server-tags plugin.
The resource point for these operations is /servers/<server_id>/tags
A user can add a single tag to the server by sending PUT request to the
/servers/<server_id>/tags/<tag>
where <tag> is any valid tag name.
A user can replace **all** current server tags to the new set of tags
by sending PUT request to the /servers/<server_id>/tags. New set of tags
must be specified in request body. This set must be in list 'tags'.
A user can remove specified tag from the server by sending DELETE request
to the /servers/<server_id>/tags/<tag>
where <tag> is tag name which user wants to remove.
A user can remove **all** tags from the server by sending DELETE request
to the /servers/<server_id>/tags
A user can get a set of server tags with information about server by sending
GET request to the /servers/<server_id>
Request returns dictionary with information about specified server, including
list 'tags' ::
{
'id': {server_id},
...
'tags': ['foo', 'bar', 'baz']
}
A user can get **only** a set of server tags by sending GET request to the
/servers/<server_id>/tags
Response ::
{
'tags': ['foo', 'bar', 'baz']
}
A user can check if a tag exists or not on a server by sending
GET /servers/{server_id}/tags/{tag}
Request returns `204 No Content` if tag exist on a server or `404 Not Found`
if tag doesn't exist on a server.
A user can filter servers in GET /servers request by new filters:
* tags
* tags-any
* not-tags
* not-tags-any
These filters can be combined. Also user can use more than one string tags
for each filter. In this case string tags for each filter must be separated
by comma: GET /servers?tags=red&tags-any=green,orange
|
