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.
This microversion doesn't require any change in novaclient's code.
Just added functional tests and changed version
Change-Id: I7f33757e6f03f172e5a13ade0aa5e8d3a10dbf01
2.8 - Add new protocol for VM console (mks)
Also, this patch removes code duplication and fixes docstrings for consoles
methods.
Co-Authored-By: jichenjc <jichenjc@cn.ibm.com>
Change-Id: Ic24183a5118872581b30f82734fa9d6ce0e53544
After the proposed bug fix, the admin can also start/stop/reset-state
instances of other tenants by passing instance name as the parameter.
Initially it could be done only through ids. One additional argument
--all-tenants is added so that the instance name is searched across all
tenants.
Previous command was:
nova start/stop/reset-state <instance_name>
New command is:
nova start/stop/reset-state <instance_name> --all-tenants
Co-Authored-By: Jyotsna <jyotsna.priya1@tcs.com>
(cherry picked from commit Ie5f8c5c15dee6060b979a34ed0aa01262e05e122)
Change-Id: I66f277b16b378a7908d8b951fe39d039df4ef6a4
Closes-Bug: #1297963
The os-hosts API uses different attribute names depending on
whether the host was returned as part of a list or not.
A host returned from 'show host' has the attribute "host"
whereas a host returned from 'list hosts' has the attribute
"host_name".
This adds a host_name property to the Host class that will set the
"host" attribute if necessary. Although this doesn't exactly mirror
the responses coming back from nova api, it will make it easier for
users to use the objects interchangeably for hosts.list() operations
and hosts.update() operations, for example.
Co-Authored-By: Chung Chih, Hung <lyan.h@inwinstack.com>
Closes-Bug: #1434167
Change-Id: I5c339bdd1ab867d972759ade9a10b86bfda1e70a
nova support accessIPv4 and accessIPv6 as input param
but nova client don't support it as input param when
doing create operation.
Because it's already support in v2.1 so no microversion
introduced.
Change-Id: Idd50fe921f8c931ee28902f90ffdde6bfba34359
Closes-Bug: 1522359
novaclient provides version negotiation on CLI layer. In case of usage
novaclient as a lib, user can specify api_version with microversion part
and can try communicate with Nova endpoint which doesn't support
microversions. Nova endpoint will not check X-OpenStack-Nova-API-Version
header and will execute request(it can be correct or not). It this case
we should warn user about his mistake and about "incorrect" response.
Change-Id: I7a5ab964b7b2b2a49cc80c22bf67ad5548afb30b
some fields such as instance.display_name can be unicode,
nova client should not translate it to 'str'. otherwise
it will report UnicodeEncodeError.
Change-Id: I4f6011105b3b11dbbcb23f3a7c1bbcf7f20bcc8c
Closes-Bug: 1518141
Added new sub command volume-attachments which displays the list
of volumes attached to a server.
Change-Id: I1f56a6fa18c35f3df2bdd11b9cf83bd5c5d9e182
Closes-Bug: #1116593
The added tests check basic set of extended server attributes
and additional attributes exposed by microversion 2.3
To avoid leak resources, cleanup part has been refactored
Change-Id: I0c8f096134838b90e17720f2a28e649998a02e3b
This is part of the work to allow Nova and Novaclient to handle endpoints both
with and without project id's. v2 version information returns a different data
structure than later versions. This patch updates the mock tests to return a
different data structure corresponding to v2 or v2.x depending on the
endpoint_type. A caller using the mock test class can set the attribute
endpoint_type to a version number, and the method get_endpoint, will return the
appropriate data structure. This is more of a workaround given the current state
of mocking Nova api calls in our unit tests.
Part of bp:service-catalog-tng
Change-Id: I61984ee592f7a5d7f1a91c9e2ff3038c0245f797
This reverts commit 036d42d7087a3c83a5feec0ad0a4c6af35df72c9
Once novaclient 2.34 is released we can merge this and
release as 3.0.0. The dependency is on the 2.34 release
request.
Change-Id: I1e3a8a8079b954fe60371c2d38ec23a10727c408
Depends-On: I4fc044e518a5cc5ea7b309a2824984a7035945bd
This reverts commit 0cd58123be5e2c2bc2f1233a3e15fb35b2ead1a0
This is a backward incompatible change that is blocking our
ability to release 2.34 for 63c7a57, which was a revert for
another backward incompatible change (2961e82) which slipped
into 2.33.
Once we release 2.34 with the bug fixes, we'll revert this
revert and release that as novaclient 3.0.
Change-Id: If79d37df3e99004897f1bb2d8564d2f1d8aa0978
This reverts commit 2961e82bfa6e375ac3c17933fac532ed316ac976
This broke cinder unit tests that have a timeout test for novaclient
where they mock the requests library raising a Timeout exception. That
test expects to get a requests Timeout passed through but with the
change being reverted it was getting a RequestTimeout exception from
novaclient, which breaks the test and fails the gate runs.
We could change the cinder unit test to handle both the requests.Timeout
and the new novaclient RequestTimeout, but that's just papering over
the cinder failure, we wouldn't know what other clients are failing
in the same way because they have code working around the requests
exceptions getting passed through, so we should treat this like an API
change.
I'd be in favor of making the same change again iff the novaclient
exceptions extended the requests exception types so it would be transparent
to consumers, since novaclient.exceptions.RequestTimeout would be a
requests.Timeout via inheritance. But given the gate breakage and it being
summit week I'm inclined to revert first and think about a better long term
fix later when people are back to discuss.
Change-Id: I368728588e5997eef860a168539eb66c58f2e72a
Closes-Bug: #1510790
Novaclient expects the requests library to always be able to get a
response back and doesn't handle other cases where it might raise
an exception even before the request is completed (e.g.
ConnectionError).
These exceptions should be captured and properly converted to some
native novaclient exception.
Change-Id: Iec7247b715c38c29910b30e76413cead4e951a37
Co-Authored-By: Kuo-tung Kao <jelly.k@inwinstack.com>
Closes-Bug: #1406586
Currently there is a baked in assumption throughout the nova ecosystem
that endpoint urls will end in {project_id}.
This means that the version document for a specific major API version
is "endpoint - last_chunk_of_url". This is not a discoverable URL,
it's one that we heuristically generate.
GET /v2.1/{project_id} is a 404.
If we make Nova able to handle endpoint ids without {project_id} we
run into a problem with novaclient, which is that end_point is now
/v2.1. The heuristic gives us a version url of /. Which returns a very
different doc than /v2.1. This causes all novaclient commands to explode.
In order to support this transition we need to make both Nova and
Novaclient handle endpoints with and without {project_id}.
The proposal is thus to try the raw value of the endpoint first. If it
works, great. If it fails with a 404, fall back to the heuristics.
While this change and the nova change are technically independent, we
should land this one as soon as possible, because clients before this
change will not work with Nova deploys that get rid of project_id in
their service catalog in the future.
Part of bp:service-catalog-tng
Co-Authored-By: Augustina Ragwitz <aragwitz+lp@pobox.com>
Change-Id: Id4a2f73cbcfcf36aea750375fd92b1c2d3cd824e
Commit d045019f0f2d28f26730b3617f7d7b993506b6e8 use the variables
API_MAX_VERSION and DEFAULT_OS_COMPUTE_API_VERSION with wrong way.
API_MAX_VERSION means the max version of client supported. This
variable only be changed when client support the new version. And
it's must bumped sequentially.
DEFAULT_OS_COMPUTE_API_VERSION is default value of option
'--os-compute-api-version', this value decided the default behaviour
of nova client. The nova client CLI behaviour should be that client
negotiate with server side to find out most recent version betweeyn
client and server. So the value should be '2.latest'. And it won't
be changed except we decided to change the default behaviour of nova
client CLI.
Change-Id: Iba9bfa136245bd2899c427ac0c231a30c00bd7f3
Closes-Bug: #1508244
Currently the metadata is parsed using
dict(v.split('=', 1) for v in metadata)
and was used in several places, it could
be better if we refactor it to a common
function. It will make it more readable
and easier to use in the future.
Change-Id: Ib0fcaacdbef65cdcb85ecc0c304f4933bef2627c
Closes-Bug: #1503939
Commit 050a0d5b304a013e23cd5909abf6e11b7dda5f18 changed the defaults
in devstack to use the keystone v3 api. This broke the novaclient
functional test job because novaclient doesn't yet support v3
and relies on having "v2.0" in the auth_url.
This appends or replaces the version in the clouds.yaml auth_url
to v2.0 to enable the functional test job to work until v3 support
is added to novaclient.
Closes-Bug: #1506103
Change-Id: I75c5efd039b71c8855acf21c5516ccbeeaaeadb3
'marker' and 'limit' are already added to flavor list, but 'sort_key'
and 'sort_dir' which are useful for pagination are missing.
Closes-bug: #1505939
Change-Id: Id78595f15fbb289133092a32238238e3c4a9d0a0
Mission 'marker' and 'limit' params for `nova flavor-list` shell
command. It would be nice to have this when there are many flavors.
Change-Id: I4579b63bc6c711f1b5eaf07b54d393ebcbfd8277
Closes-bug: #1505874
When running functional tests in a slow virtual environment,
the given timeout of 10 seconds to list thr available instances
is not enough. Increase the timeout to not run into
a "timed out (HTTP 408)".
Change-Id: Ie2345e6858bcc97095863d5d388bacf9c29b7682
This reverts commit 01c2e60eb3f3718884dd77cb05b4cde76052fb9d
The server side change isn't in yet, there is a spec
proposed:
I167141676ef4f597a1c022c1fd5dc96fd55d02ad
So this should have never landed in the client. And when
it does it should be using microversions, like we have for
the v2.4 support added in:
5fdb861ad4835513c0cb78251cce85ac73f51dd4
Change-Id: If3196093036c72f0f86cdca98a016b9f4fff0923
When raising API_MAX_VERSION to support a new Nova API microversion
there should be support added to some method to account for the change.
A test has been added to catch if support has not been added. In the
event that no methods need to change there is an exclusion mechanism in
the test so the version and a note can be added there.
Change-Id: Iebc1be2557e1b6eec327b703568805578e564172
The client currently implements support for microversions 2.2, 2.4 and
2.11.
According the nova API microversion history:
http://docs.openstack.org/developer/nova/api_microversion_history.html
2.3 just returns extra attributes in the response so it's not a problem
for the client. We should expose those at some point but it's not a
breaking change.
2.5 is a server-side only change since the client allows filtering
servers by IPv6 address but the server wasn't honoring that until 2.5.
There are no client side changes for that microversion.
2.6 is the first backwards incompatible microversion since it replaces
the old specific console APIs (RDP/serial/SPICE/VNC) with a new generic
remote-consoles API. The client must be updated to handle this since
requesting any microversion >=2.6 for consoles will fail right now. This
is exposed on the CLI right now because the CLI defaults to the 2.latest
microversion.
So even though the client actually supports the 2.11 microversion, we
shouldn't default to higher than 2.5 because we have gaps in handling
2.6->2.10.
This change fixes the default for the CLI by setting
DEFAULT_OS_COMPUTE_API_VERSION=2.5.
Partial-Bug: #1500688
Change-Id: I52074f9a3e7faa6a7a51c3fa9766100acf25dee2
