We already have a document on how to run unit tests, so
development.environment should just point to that document instead of
trying to summarize it. Keeping this information in one less places
makes it easier to make sure the page is up to date (which
development.environment is not -- no mention of tox).
Change-Id: I9aecf439b6145b035b3457559ddb187058f5057b
Don't keep a copy of the run_tests.sh flag list here since it
inevitably will get out of sync with the real list.
No need to go into detail on how unit testing is set up, since we already have a wiki
on how to run tests that applies for all OpenStack projects. Keep
section with tox examples since that is the most commonly used command.
Change-Id: Ia8eb059be164d9df3edfd69aedcebfd028da45ff
Related-Bug: 1219040
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
The nova client already has the following flavor commands:
flavor-access-add Add flavor access for the given tenant.
flavor-access-list Print access information about the given flavor.
flavor-access-remove Remove flavor access for the given tenant.
flavor-create Create a new flavor
flavor-delete Delete a specific flavor
flavor-key Set or unset extra_spec for a flavor.
flavor-list Print a list of available 'flavors' (sizes of
flavor-show Show details about the given flavor.
This covers what nova-manage flavor was providing so let's deprecate the
legacy nova-manage subcommand and mark it for removal in the K release.
There is not a bug or blueprint for this. The flavor subcommand is
completely duplicated in nova client. It is accessing the database
directly and we want to move to using flavor objects which would go
through conductor. So this could be considered part of the objects
conversion for flavors.
For some other commands like service, db and host it makes sense to
leave those so you can access the database before the api service is
running, but that's not the case for flavors.
UpgradeImpact: nova-manage flavor command is deprecated, use nova client
Change-Id: I8709bc9af4e490142e44c6dc61fd0aaa3a392b68
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
As of commit 07ee9639 three years ago nova-manage.conf is no longer
used, so let's clean up the man page.
Closes-Bug: #1304580
Change-Id: Ie061733da4bd0337f510e17b6dd7ca5bae14b7de
Server group scheduler filters were added to the default set of
scheduler filters. Update the docs to reflect the updated defaults.
Change-Id: I614cf83e419c93038fc4ed7287ec743cedb4860e
Related-bug: #1303983
ServerGroupAffinityFilter was used instead of
ServerGroupAntiAffinityFilter in the filter description.
Change-Id: I16721db5a7dcf90e72047dd5ca5a4f55088c147d
* Renames the os-instance_actions v3 plugin to os-server-actions
* Also modifies api specific tests and expected user input JSON
* DocImpact only for v3 Nova api documentation for this plugin.
Closes-Bug: #1206032
DocImpact
Change-Id: Id5049e10f5ef540d0d8e3871d800e9d9cb33da73
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 9e770e62135fe9c2c8ac0121a5a79245b25a7847, 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
The deprecated group filters do not work if both are enabled at the
same time. Add this in a note in the docs on the different scheduler
filters.
DocImpact
Related-bug: #1296913
Change-Id: Ic0e1b8b59c8a462e193dffb3b0f873d8aa35aa3c
Prior to Icehouse, there was a different type of handling of the
'group' scheduler hint that got lost in the completion of the server
groups API. This patch completes the code necessary to provide
backwards compatibility with the old behavior.
Previously, the policy for groups was simply based on what scheduler
filters you had enabled. You could have either the affinity or
anti-affinity filter enabled and that would be applied to all groups.
These filters now act on groups with a policy type of 'legacy'.
New filters have been added that can be enabled simultaneously and act
based on the policy set on the group via the server group API.
DocImpact
Change-Id: Ia65c151396415ca48725cb3c756f33efa01d2fe5
Closes-bug: #1296913
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 6ba248635b70860a44e486e7739efa4cc6612ce6
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
This bug and fix is not about deleting run_tests.sh.
The change to delete run_tests.sh has been abandoned.
Thus the documentation of run_tests.sh remains.
Change-Id: Ia0a883260affc56c148dbebc5e3a49acb36b067e
Closes-Bug: #1282393
Enhanced the discussion of tools/install_venv.py to say that it
installs the items listed in test-requirements.txt as well as
those listed in requirements.txt.
Re-wrapped the relevant paragraph.
Since the change to delete run_tests.sh and tools/install_venv.py
(https://review.openstack.org/#/c/76627/)
has been abandoned, the doc of install_venv.py should still be
accurate.
Change-Id: I5cfd9f179f40b2418129067d0940bfdbf47512cb
Closes-Bug: #1266671
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
