setUp method of base class for functional tests creates an instance of
novaclient.client.Client with const version. This logic is wrong since we
have tests for microversions.
Change-Id: Ibd3ee5c730ae1fb3c19f512728f2a0a3693763e8
The ID (primary key) of a resource can not be retrived by the client.
There is no sense to provide the functionality to get an resource by
its ID. Especially when an instance is named by an interger, client
will try to get the instance with the ID of that interger value.
This patch will change the order in which the novaclient retrive
resources. First by UUID, then by name, finally by the ID. This will
also reduce api call overhead, since UUID is used mostly.
Change-Id: I0bfa5cb03a04625c3def5608dd4529e52d50f944
Closes-Bug: #1516924
novaclient should display help message of the proper versioned method
(based on api_version value).
Closes-Bug: #1523649
Closes-Bug: #1523651
Change-Id: I67f7fc2befde9d312400e9a1569e590bd763156e
2.12 - 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.
novaclient.base.Resource class is a parent class of VirtualInterface resource.
Since `Resource` is a universal interface for any resources and doesn't
require hard-code attributes which describe partial resource, there are no
required changes to support this microversion in "novaclient as a lib".
"novaclient as CLI" doesn't provide an interface for VirtualInterface yet
(see bug 1522424 for more details). When it will be implemented, we will need
to check that new attribute is displayed correctly.
Based on the fact that 1522424 is not resolved and novaclient.base.Resource
class has enough tests, this patch doesn't require any tests.
Also this patch fixes representation of VirtualInterface resource.
Change-Id: I18cf23847d3b2b01f5a6ffae2ebc4bede54babce
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.
Change-Id: I13ca3f8a4dd9cf11bec79966bb8a2ab48847be22
There is a lot of H404/405 violations in novaclient, and it is better
to fix those to have a better doc string for class/methods.
This patch fixes these violations for files under novaclient/tests/
folder.
As there are lot of violations and cannot be fixed in single patches,
So separating those in multiple patches for easy review.
Partial-Bug: #1521899
Change-Id: I6e712ece14c745013bfba0bee9d77e7875dd2263
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
