Currently when return compute node information, there is no status returned.
When the corresponding service is disabled or down and users try to
do 'hypervisor-list' or 'hypervisor-show', they will have no idea of it.
Implements: blueprint return-status-for-hypervisor-node
Closes-Bug: #1285259
DocImpact
Change-Id: I17c53b454ccef023f298f1b8875daef965d2325d
In the event of an unrecoverable hardware failure, support needs to
relocate an instance to another compute so it can be rebuilt.
The changes involved in this patch are:
[*] Add a new v2 extension to determine that the host argument
on evacuate is now optional.(Extended_evacuate_find_host)
[*] Doc regeneration.
DocImpact: The evacuate target host is now optional.
If 'host' field is not sent in the request, the scheduler will
determine the target host.
This will include nova client changes ( on the proper commit ) to support
this new optional parameter.
Implements: blueprint find-host-and-evacuate-instance
Change-Id: Ib34fb3120263b746ad2f8fe89c14137e36a07a53
Co-Authored-By: Juan M. Olle <juan.m.olle@intel.com>
Co-Authored-By: Andres Buraschi <andres.buraschi@intel.com>
Co-Authored-By: Anuj Mathur <anujm@thoughtworks.com>
Co-Authored-By: Navneet Kumar <navneetk@thoughtworks.com>
Co-Authored-By: Claxton Correya <claxton@gmail.com>
The agent_id should be integer for agent create and index. But in
the api sample file it is string type. It's because the api sample
tests provide agent_id with string type in fake data. This patch
correct the api sample files and tests.
For agent update, it use agent_id that passed from url, make the
response use string for agent_id. We can't fix this problem for
back-compatibility. This will be fix in the future after v3 API
expose by micro-version
Change-Id: I262b4b26c94dba003e80bda2f38d2e985ef9f220
Partial-Bug: #1333494
If a service is enabled, the "disabled_reason" field in response
for /v2/.{tenant_id}./os-services/detail is null, however, currently
it's specified as "" in the doc, thus may be confusing to users.
This patch change the template and doc, it should not cause issue to
existing applications.
Change-Id: Ia71ec4c97a355bcc1a7b63e6107db77f80a5d843
Close-bug: 1328382
This reverts commit 7d22153d05.
The quota_classes API was used to set default quota values
so it shouldn't have been removed, so reverting a series
of changes that removed the API and it's internal code.
Related mailing list thread on the topic:
http://lists.openstack.org/pipermail/openstack-dev/2014-May/035383.html
Partial-Bug: #1299517
Conflicts:
doc/api_samples/all_extensions/extensions-get-resp.json
doc/api_samples/all_extensions/extensions-get-resp.xml
nova/tests/integrated/api_samples/all_extensions/extensions-get-resp.xml.tpl
The conflicts are due to Mark McLoughlin's timestamp-format series
of changes on master (Juno).
Also note that quota_classes.py was changed due to
commit c75a15a4 to rename the NotAuthorized exception
to Forbidden.
Change-Id: I7890e6b41d4ebf19944c1d4db65111fcc4c45463
An SSH key generated by Nova contains the comment 'Generated by Nova'. Older
versions (prior to 0.7.2) of cloud-init trip over the spaces in the comment
and as a result of that the key injected into the root account is not disabled
by cloud-init. Yes, it's a cloud-init bug but it's also a regression in the
sense that older OpenStack installations (Essex and older) don't contain
spaces in Nova generated key comments and thus older cloud-init's are not
affected in these environments.
This patch replaces the spaces with dashes, i.e., 'Generated-by-Nova'.
Spaces were introduced by commit: 114109dbf4
Ubuntu cloud images with cloud-init < 0.7.2: 10.04 LTS and 12.04 LTS
cloud-init bug report: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1220273
Closes-Bug: #1297685
Change-Id: I1761f61dfbba58be98351ae4a51884b03268cf09
datetime objects are serialized into xml using simply str() and this
is a slightly different format from ISO8601 in that the date isn't
separated from the time using 'T'.
(However, note that the iso8601 library happily accepts this format)
Add a specific regexp for this format so we can test for it in the
places we know it is used. This also means we can remove the generic
%(timestamp)s regexp.
Note that unlike the isotime and strtime formats, whether this format
includes timezone or microsecond information depends on whether the
datetime object had those fields set. The isotime format always
includes a timezone but not microseconds, whereas the strtime format
never includes a timezone but always includes microseconds.
There are a small number of examples where this format is used in JSON
too - e.g. the instance usage audit log extension pre-serializes its
timestamps by doing:
return dict(period_beginning=str(begin),
period_ending=str(end),
Using a name like 'xmltime' for the timestamp format used in cases
like this actually makes sense - it highlights that the format used
in this case is a weird mistake.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I70f839ac17273ed10078b833aeba308bd5e994e1
This patch adds the new API Sample file and its test for Nova V2 and V3
get keypair APIs.
This patch extend the timstamps reg exp to allow the combination
of TZ and microsecond/
Closes-Bug: 1298769
Closes-Bug: 1298818
Change-Id: If695a23cf95862b7bec6fbc5bdf7fc1733d08d4a
Any datetime objects that get serialized via jsonutils.dumps() get
stringified using strtime() which includes decimal seconds and is
timezone naive.
Use a specific regexp to check the use of this format.
Note that included in here is a fixup to the doc samples for the
instance actions extension - the sample shows it using the
str(datetime) format when in fact it is using strtime. This came
about because before commit 68288b9 we were using a pre-serialized
timestamp in the fake instance actions. I just regenerated the samples
for this.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: If52a2a664eccc8aed8a39d1a9dfb0209337c3c79
The fake networks use a pre-serialized timestamp in str(datetime)
format which which doesn't give us the opportunity to test the
serialization code properly and isn't the format use in practice.
Use real dateime objects instead.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I5cbe722fb59cdd326b4c75dcfea14f206d71f668
It's unusual to include a '+00:00' offset in an ISO8601 timestamp
rather than just using the 'Z' suffix. It's also very weird for our
API to be returning timestamps which aren't in UTC.
Let's make these timestamps consistent with other timestamps by
using UTC always and representing that with a 'Z' suffix. Also,
enforce this in the API sample tests by using a new 'isotime' regexp.
A small number of the extensions in the API sample templates
specified the exact timestamp, so templatize those before regenerating
the API samples for GET /extensions.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: Idf429e55e4ae13738ac531a25ce54b20d395410d
In a subsequent commit, I make a change which requires regenerating
this API sample but doing so shows up a bunch of unrelated changes.
This commit simply regenerates the API sample without any functional
changes to highlight the non-functional sample changes.
Change-Id: I5fafff90f20af17d787039568245f598e500405e
This commit includes the V2 changes.
Making changes in v2 API to take an extra parameter rescue_image_ref
as part of the rescue action API.
If specified, this image_ref will be used to rescue the instance.
If the image is not specified, then the base image ref is used by
default.
Partially Implements: blueprint allow-image-to-be-specified-during-rescue
DocImpact
Change-Id: I985b21264841a6a18a66d19ccd41753f78576776
Current keypair sample files 'keypairs-get-resp.json/xml contain
'keypairs' as the first key and that means its sample response
of "list keypairs" API not "get keypair" API.
The tests don't pass a keypair id, so current tests also are for
"list keypairs" API.
Details-
Below API sample files- from their name it looks like these are for
get keypair API. But in actual content of these files are written as
List keypair API response. So it create the confusion that for which
API these API sample file are. Name suggest for GET and content
suggest for LIST Keypair.
/nova/tests/integrated/api_samples/os-keypairs/
keypairs-get-resp.json.tpl
/nova/tests/integrated/api_samples/os-keypairs/
keypairs-get-resp.xml.tpl
Their API sample test cases are written corrosponding to list keypair
APIs.
This patch correct the above API sample file name from get to list
Keypair APIs.
API Sample test cases names are also modified accordingly.
Partial-Bug: 1298769
Change-Id: I88d894ff9b0f6236221fa922601b641f26a87301
This is a follow up to 9e770e6213, which
missed the change in a duplicate copy of host_status.
Add regression test to test_virt_drivers.
This requires changes to the API samples, because they were wrong. virt
drivers use convert_version_to_int which converts a version string to a
4 digit number ("1.0" becomes to 1000)
Change-Id: I28ce23509e3c9feae183a49a8fc5bf3c7c601295
Closes-Bug: #1285035
Avoid adding the current tenant to the flavor access list when
a private flavor is created. In ordeir to add tenants to the
flavor access list we should use the add_tenant api.
Tempest has to be updated accordingly:
https://review.openstack.org/81551
Documentation has to be updated as well:
https://review.openstack.org/82175
Partially (just for the V2 API rather than V2 and V3)
reverts commit 6ba248635b
Fixes unittest which was added in the original commit so it checks
for the behaviour we have now rather than the behaviour after the
backwards incompatible change which is being reverted.
Change-Id: I731081b6df0d96df1bc1763d214d28c62bbbb51c
Closes-Bug: #1286297
Now there are not API sample files of "unshelve a server" and
"shelve-offload" APIs, and OpenStack API documentation also
does not show these APIs.
This patch adds these API sample files.
DocImpact
Closes-Bug: #1285482
Change-Id: Idf797eb6723b94abae71a77c12bc2bb9b330fa28
Ensure that API does not allow conflicting policies to be configured
on an instance group. More specifically the user should not be allowed
to configured 'anti-affinity' and 'affinity' on the same instance group.
In addition to this a validation will also be done on the policy, that is,
if the policy is not supported then an exception will be raised.
This is part of blueprint instance-group-api-extension.
Change-Id: Id19c55cb60109819429f73e2b28efe7f15cc5194
Support the Creation, Read, Delete, and List of server groups.
Refactored the code to use objects (https://review.openstack.org/#/c/38979/
Renamed from "instance group" to "server group".
Implements: blueprint instance-group-api-extension
Change-Id: I650a8f191dea5eab5b4b1828f0b9f65e33edea2a
Corrects the api samples for the V2 os-assisted-volume-snapshots.
The api samples for the create path were incorrect. This patch fixes
them so the documentation for the API will be correct. It doesn't fix
the input validation as it would be a backwards incompatible change.
Closes-Bug: 1286936
Change-Id: I66a9162e637e3d65bcbd7d033c6c173e67178fbe
Implements: blueprint hyper-v-rdp-console
Currently graphical console access to Nova instances is limited to
clients which are part of Nova itself (novnc, xvpvnc, spice-html5).
The mentioned clients verify the validity of a console access token
with the following private API:
nova.consoleauth.rpcapi.ConsoleAuthAPI.check_token
The usage of a private API precludes the possibility of employing
external graphical console clients, including FreeRDP-WebConnect, used
to connect to Hyper-V instances via RDP.
This change adds a public API method that wraps the aforementioned
check_token private API. This allows external clients to obtain the
necessary protocol connection information by providing a token
previously obtained with calls to get_vnc_console, get_spice_console
or get_rdp_console.
Includes V2 and V3 API implementations.
Change-Id: Idd1e4f57b16bd1488f3b72bb064cef51321a7c79
It turns out os-quota-classes-sets never worked
(http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html). Since this doesn't work no need to keep it around.
V3 removal: Id1f288baa723df825151bd84aa27089271c2b8e4
Original commit: I6b6477481187d16af225d33c1989430e4071d5a8
This patch just removes the API it doesn't remove the quota-class
internals, that will be done in a subsequent patch.
Change-Id: I1110022d6f628d03aaf363da707f2d2ef1600437
Services and related compute nodes cannot currently be deleted
from the command-line. If a node is retired, the service list
will continue to show the retired services.
A delete service REST method has been added to the compute
APIs to support the command-line removal of retired services.
Blueprint: remove-nova-compute
Change-Id: I655a7f818bb59c8971feb5841feeefafc3a4580a
Flags: DocImpact
Implements: blueprint hyper-v-rdp-console
Nova currently supports VNC and SPICE remote console protocols. This
commit adds support for the RDP protocol in a similar way.
Change-Id: I2c219d4a200122c6d6cfcbd8e074dca0f6fea598
After no-compute-fanout-to-scheduler, host_ip was stored in the table
of compute_nodes. Host ip address should be considered as the hypervisor
attribute similar to the hypervisor_type, hypervisor_version etc, and
now those attributes such as hypervisor_type, hypervisor_version etc
are all listed as the hypervisor attribute when calling "nova
hypervisor-show host", so we can also set "host_ip" as a new attribute
output for this command.
DocImpact
1) Only administrators can view hypervisor detail in nova.
2) It can help improve debug capabilities for nova. For example, if
admin using SimpleCIDRAffinityFilter, then after VM is deployed, admin
can check if the VM was deployed successfully to the desired host by
checking ip address of the host via "nova hypervisor-show host".
3) Add host_ip to the output for "nova hypervisor-show"
Implement bp hypervisor-show-ip
Change-Id: I006a504d030be1f47beb68a844647026a6daf0ce
The preserve_ephemeral option for rebuild will preserve the content of
the ephemeral partition, making stateful golden image based
deployments possible even when clouds haven't deployed Cinder, or the
hypervisor doesn't support Cinder (e.g. BareMetal / Ironic).
Partial-Bug: #1174154
blueprint: baremetal-preserve-ephemeral
Co-Authored-By: Robert Collins <rbtcollins@hp.com>
Change-Id: Id33d5d4107f89814842a3f0b7f33690dd7e3aadc
As discussed at the summit in the QA stream, this removes
the coverage extension from the V2 API.
According to the API Change Guidelines
https://wiki.openstack.org/wiki/APIChangeGuidelines
we should not be doing this. However the coverage
extension is a rather special case. It has security issues
such that it shouldn't be used in a production cloud
environment. It also doesn't work properly so its usefulness
to measure API coverage is limited. And in the past the presence of
this plugin has been used as a reason not to accept
an alternative technique to measure API coverage.
This is the proposed replacement
https://review.openstack.org/#/c/25882/
Change-Id: I07d798129ee277a6f7691c25f88c07a5204c0943
Add fields: uuid, task_state, updated_at, and pxe_config_path
to aid system admins in troubleshooting issues.
Fixes bug 1184449
Change-Id: Ia4c03cb228b3efe602455bf05883ddf03b7f18da
a private flavor
In FlavorManage extension, a change has been made to
create flavor-access for a corresponding tenant on
creating a private flavor
This also requires the api-samples for flavor-access
to be changed, since there will be a flavor-access created
by default on creating a private flavor
This commit has a DocImpact
Change-Id: I7795fbd04ae9fc8b1ea6fb27203dfa5217d310ce
Fixes: bug 1209101
Add a new API extension that exposes assisted volume snapshot
capabilities. This extension is admin only by default. We expect it to
only be called by Cinder. If you have your deployment set up in such a
way that your adminURL is different from the public, this extension can
only be loaded in the admin API instance. Cinder will pull that URL out
of the service catalog to use.
Part of blueprint qemu-assisted-snapshots
Change-Id: I79e22ab6ef66fa16dc534a4336e766065702b2f5
Adds version information for the V3 API which is only displayed
when the V3 API is enabled. Even if the the V3 API is enabled the
V3 API status is "EXPERIMENTAL" and the V2 one "CURRENT". This was
done so autodiscovery tools would not yet use the V3 version by
default.
Ports the relevant parts of the version extension and associated
tests to the V3 API to display V3 version information for /v3 GET
requests.
DocImpact
Partially implements blueprint nova-v3-api
Change-Id: Idd335ce0df63d91e94a4a757f1fbae94b576c37e
Start the consoleauth service, otherwise authorize_console() will fail
if we start timing out call()s in the fake RPC driver when there are no
consumers for a topic.
blueprint: oslo-messaging
Change-Id: Ieee37a0370c0b548c589a0573e6e8a68e10a6fdc
get_available_resources is actually used by the scheduler while
get_host_stats was previously used, and is still used for host
capabilities. This patch makes get_available_resources and
get_host_stats use the same logic to clean up the code. As part of
making them use the same logic, some of the unused data returned from
get_host_stats is changed to be what get_available_resources expects.
This is also in preparation for removing the periodic RPC fanout from
compute nodes to the scheduler.
This patch cleans up libvirt and fake drivers only. This is not needed
for other virt backends as this is a cleanup only. Further cleanup of
libvirt and other drivers will happen after get_host_stats isn't used
for the compute fanout to schedulers.
Because this makes a change to the fake driver, several api samples
needed to be changed as well. The fake driver is changed so the
test_virt_driver tests can continue to be used
Part of bp no-compute-fanout-to-scheduler
Change-Id: I1eec5c117a1cb0490e9f9c09e731909bc31698a9
Somehow, the instance actions API was different in three places:
1. The actual API from a running system
2. The regular unit tests
3. The api_samples tests
This fixes the fake_instance_actions module to look like the database
model (which was the root of the problem) as well as the api_samples
and regular unit tests to properly confirm the actual behavior I
validated manually against a running system. This looks like it
changes the external API, but in fact, it makes things match what
the external API actually is.
Change-Id: I0c8ddff3e0819a65667617083dfaa74f7317cc05
This patch makes the nova API aware and able to accept the new block
device mapping format introduced in
If30afdb59d4c4268b97d3d10270df2cc729a0c4c when booting an instance.
It does so by introducing a new extension into the v2 API. There is no
v3 extension as part of this patch because volume extension is going
away in v3 and thus this functionality can be part of the core servers
extension. This will be done in a subsequent patch.
The compute API create method will still convert these back to the
legacy format for the time being until the compute API will know how to
take advantage of the new format.
As this change adds the new API extension, marking it as DocImpact so
that the changes and the API data format can be documented.
blueprint: improve-block-device-handling
Change-Id: I2c1b63e41deca26f727fb9ed912a55494db9c76c
Adds support for transparently swapping an attached volume with
another volume. Note that this overwrites all data on the new
volume with data from the old volume.
Implements blueprint volume-swap
Change-Id: Iaace71f46acd33cf1531d953d569c0b6d0bbe680
Implements blueprint per-user-quotas.
Fixes bug 968175
Based on the original quotas structure.
NOTE:
quota_instances, quota_cores, quota_ram, quota_key_pairs and
quota_security_groups are supported per user.
Add CRUD methods for project user quotas API. DocImpact
- Shows quotas for a user.
GET v2/{tenant_id}/os-quota-sets/{tenant_id}?user_id={user_id}
- Updates quotas for a user.
POST v2/{tenant_id}/os-quota-sets/{tenant_id}?user_id={user_id}
Add commands for project user quotas management.
- Show user quotas:
nova-manage project quota --project <Project name> --user <User name>
- Update/Create user quotas:
nova-manage project quota --project <Project name> --user <User name>
--key <key> --value <value>
Change-Id: I24af1f6bc439d5d740303c6fe176a9bffe754579
Adds new 'shelve', 'shelveOffload'/'shelve_offload'(V3), and 'unshelve'
actions to the API. Exposes the functionality already provided in the
compute api.
Part of bp shelve-instance
Co-author: Dan Smith <danms@us.ibm.com> (Instance objects)
Change-Id: Idd485b591730c6ac025ee57a1242afdd02191b2f
- adds an API extension to include list of attached volumes with instance info
- adds v3 api porting as well
DocImpact
Implements blueprint servers-add-volume-list
Change-Id: If58dc40b093c2f61c6ae6b82fcd8f0bf53be464a
The os-migrations extension exposes endpoint to fetch all migrations.
The migrations can filtered by host and status. If cells are
enabled migrations can be listed for all cells or can be filtered for a
particular cell.
The route for fetching migrations for
a region is - v2/{tenant_id}/os-migrations. Filters can be passed as
query parameters -
v2/{tenant_id}/os-migrations?host=host1&status=finished&cell_name=Child
DocImpact
Change-Id: Id70dbece344a722b2dc8c593dd340ef747eb43d3
Implements: blueprint list-resizes-through-admin-api
The previous rate limit defaults were unusable in any deployment.
Rate limiting to 10 POSTS per minute and 50 servers per day seems
to low, especially when we can use quotas to actually limit the amount
of resources a user can consume.
Update docstring to explain what the rate limiting is used for.
Fixes bug 1178529
DocImpact changed default values
Change-Id: I8cc93423f76d9b0a5135adf69babc4ff355a0951
Yunhong Jiang