This changeset enables support for Keystone V3 authentication
on the Nova CLI. This provides consistency between using
novaclient as the Nova CLI and using it as a library
as the Keystone V3 support already exists for the libary usecase.
The bulk of the change surrounds the use of the keystoneclient
session object for authentication, retriving the service catalog,
and HTTP connection/session management.
Co-Authored-By: Morgan Fainberg <morgan.fainberg@gmail.com>
Change-Id: Iece9f41320a8770176c7eeb5acd86be4d80cc58f
* E265 block comment should start with '# '
* H302 import only modules
Do not check docs/source/conf.py. The file is imported from the
cookiecutter template.
Documented why checks are ignored and if they should be enabled
in the future.
Change-Id: I367064ecaa6d1fd9d918f7ce003303e2db660647
Jamie added some excellent "Using Sessions" docs to keystoneclient in
I5e44c1029ce160cb2798cfb8a535aa9f3311799a. These will be published to
http://docs.openstack.org/developer/python-keystoneclient/using-sessions.html
once the version after 0.9.0 is released.
Let's add a brief example on how to use this API and reference the
keystoneclient docs.
Change-Id: Icbcef45f13c1f962c90aa3db9dde4360520166ff
The session object is a cross-client means of standardizing the
transport layer.
Novaclient's HTTPClient object has diverged significantly from other
clients. It is easier to simply replace it if a session is provided. If
a session is provided then users of the library need to be aware that
functions such as authenticate() will no longer have any effect/are in
error because this is no longer managed by nova.
Change-Id: I8f146b878908239d9b6c1c7d6cdc01c7e124f4e5
The client __init__ method takes both a project_id and tenant_id which is
rather confusing as in the Nova API these terms are used interchangeably. The
comment clarifies the difference between a project_id and tenant_id
when using novaclient.
For backwards compatibility reasons we can't really change the names (though for V3
perhaps we should in the future).
Change-Id: I569fe9318335c8d686153b0936205cb190e01ef1
There are a few things currently wrong with bash-completion as it stands now:
1) IDs are currently required to be UUIDs. This is an arbitrary limitation
and doesn't make sense for certain kinds of objects, like `Flavors`
where a valid ID could be `performance-16gb`.
2) The code is spread out between Oslo's `Resource` and Novaclient's
`Manager` class. This makes it difficult to improve the code because it
requires changes to two separate projects. We should centralize the
code in Novaclient until the API is stable, then import the code into
Oslo in its entirety, not partially like it is now.
3) The completion code is handled by the `Manager` of which there is one
per Resource-type. In the interest of centralizing this functionality,
we should create a `CompletionCache` class and hang it off of `Client`
of which there is one-per-session.
4) The completion-code currently runs by default even in headless mode
(e.g. novaclient without the shell). It'd be much more efficient to
only write to the completion cache if we're accessing the `Client` from
the novaclient shell. We can make this an option to support third-party
CLI clients that want to use the completion-cache as well.
NOTE:
* The corresponding Oslo patch is here:
https://review.openstack.org/#/c/101376/
* This patch was tested in multithreaded mode to prevent any regression
from:
https://bugs.launchpad.net/python-novaclient/+bug/1213958.
Change-Id: Idada83de103358974b739f81d4f392574f9e1237
Closes-Bug: 1332270
Commit 1b15b23b0a629e00913a40c5def42e5ca887071c removed the
os-quota-class-sets v3 API from Nova in Icehouse. This change removes
the corresponding client code.
Closes-Bug: #1331095
Change-Id: Iaa2f4063e0f671da5a54ff89d0f1c1780a2687c4
Nova returns available extension list through its REST API.
The command of v2 API has been implemented, and this patch adds the
one of v3 API.
Note:
The command name of v2 is "nova list-extensions" but the one of v3,
which this patch adds, is "nova extension-list" because the name fits
to the other command names.
Change-Id: Ibee712b0aa5898a94e362f20be71e8863500b195
Prior to this patch, novaclient was handling sessions in an inconsistent
manner.
Every time we created a client instance, it would use a global
connection pool, which made it difficult to use in a process that is
meant to be forked.
Obviously sessions like the ones provided by the requests library that
will automatically cause connections to be kept alive should not be
implicit. This patch moves the novaclient back to the age of a single
session-less request call by default, but also adds two more
resource-reuse friendly options that a user needs to be explicit about.
The first one is that both v1_1 and v3 clients can now be used as
context managers,. where the session will be kept open (and thus the
connection kept-alive) for the duration of the with block. This is far
more ideal for a web worker use-case as the session can be made
request-long.
The second one is the per-instance session. This is very similar to what
we had up until now, except it is not a global object so forking is
possible as long as each child instantiates it's own client. The session
once created will be kept open for the duration of the client object
lifetime.
Please note: client instances are not thread safe. As can be seen from
above forking example - if you wish to use threading/multiprocessing,
you *must not* share client instances.
DocImpact
Related-bug: #1247056
Closes-Bug: #1297796
Co-authored-by: Nikola Dipanov <ndipanov@redhat.com>
Change-Id: Id59e48f61bb3f3c6223302355c849e1e99673410
In Keystone V3 user names are no longer necessarily unique
accross domains.
A user can still authenticate a user in the non default
domain via the V2 API providng they use IDs instead of names.
Tenant_ID is already supported, this change adds support
for user ID
Change-Id: I36ba75f3e67c8cdb959e31923d5e557414ab6f9b
quota-classes API was already removed.
Change-Id: I1110022d6f628d03aaf363da707f2d2ef1600437
This patch removed quota-class subcommand from nova client.
Change-Id: I18bf7c255fabdb52c8ce8159f68c3e5c70e54993
Adds --os-auth-token (matching Glance client at least) to accept a
pre-obtained authentication token.
CS will be called iff:
One or both of token and URL are not provided;
AND the cache is empty/disabled or we don't have a tenant-id.
Removed some code altering the auth request to a GET if a token is
supplied - did not work for me and I think the path was dead previously.
Fixed test to account for this change.
Completes blueprint token-endpoint-instantiation
Change-Id: I67410b80e506bb80c152223cd113b7139a62a536
Adds the ability to attach, detach and swap volumes on
servers. There is no code shared with the v1_1 version
because for V3 the volumes interface is completely different
and the attach/detach/swap functionality is simply a server
action rather than something accessed through a special resource.
Partially implements blueprint v3-api
Change-Id: Ib405f821fe557745d11cff9db08381fc15233fe5
- Removes vim headers: It's not needed to set tabstop tons of times,
this can be done by setting vimrc.
- I did not update files in common/* and install_venv_common.py because
these files are sync with oslo.
Note:
http://lists.openstack.org/pipermail/openstack-dev/2013-October/017353.html
Closes-Bug: #1265474
Change-Id: Ia09dc2c908187a756bf55eaba74655484304517d
Adds support and tests for the os-simple-tenant-usage
extension for the Nova V3 API. There are no
differences between the V2 and V3 API and this change
adds the client code to enable the usage command. Note
that with nomenclature change from tenant to project
occuring in Nova there will be a difference between
the V2 and V3 API in the future.
Differences between the V2 and V3 API are described here:
https://wiki.openstack.org/wiki/NovaAPIv2tov3
Partially implements blueprint v3-api
Change-Id: Iddf6211c9c87cbb191d9a5d5a65710b343c30e67
Adds support and tests for the keypairs extension for
the Nova V3 API. The V3 version of the keypair extension
has been made part of the core V3 API and as a result no longer
has the "os-" prefix in the url.
Differences between the V2 and V3 API are described here:
https://wiki.openstack.org/wiki/NovaAPIv2tov3
Partially implements blueprint v3-api
Change-Id: Id4a77e1e4565f63ecdf7753d3c224975519fc07c
Adds support and tests for the os-certificates extension
for the Nova V3 API
Partially implements blueprint v3-api
Change-Id: I9a75bf04a7047af6c501af2df72de4b8ce3462b0
Adds support and tests for the os-aggregates extension
for the Nova V3 API.
Partially implements blueprint v3-api
Change-Id: Ibe251f083ea444fb46aac9cc5cf08784b5826ad7
Adds support and tests for the os-hypervisors extension
for the Nova V3 API.
Note that compared to the V2 API it separates the search
function into search by hypervisor name and a new list
servers by hypervisor as this better first the changes
in the V3 API. The listing of servers by hypervisor command
is preserved, though reworked to use the new interfaces.
Partially implements blueprint v3-api
Change-Id: I472f9acad895dcf842e93d2de27530652f73867e
Adds support and tests for the os-services extension
for the Nova V3 API
Partially implements blueprint v3-api
Change-Id: Ic64e465e24a6e840c567677d4f2ea9d63b742ccd
Adds support and tests for the os-quota-class-sets
extension for the Nova V3 API. Note that compared to
the V2 version this removes the ability to set quotas
which are not relevant to the V3 API (eg injected file
quotas are not relevant because the os-personalities
extension has been removed).
Partially implements blueprint v3-api
Change-Id: I3e7f36407f2f59737ecbce2c8ce014cef623ecdc
Adds support and tests for the os-quotas extension
for the Nova V3 API. Note that compared to the V2
version this removes the ability to set quotas
which are not relevant to the V3 API (eg injected
file quotas are not relevant because the
os-personalities extension has been removed)
Partially implements blueprint v3-api
Change-Id: Ifa1c77428424bedf7fb88ef6d7b3843376799d24
Adds support and tests for the os-availability-zones
extension for the Nova V3 API. Also implements
sorting for zone host display which was applied
to the v1_1 version, but not the v3 version in
I9ab25ef52d6d19b45a39f04cbcde864ee225b4cc
Partially implements blueprint v3-api
Change-Id: I8daa2503a2dc8767e9157bdfa6c9adaedfc8f3c0
Ports servers support from the v1_1 directory omitting functionality
which is no longer supported directly in the V3 API such as:
- floating ip
- add/remove/list of security groups
- disk config related functionality
Makes the appropriate modifications required for parameter name
changes between the V2 and V3 API
Booting an instance is not yet supported as this will require more
extensive changes as image listing services are no longer proxied
through the Nova V3 API
Partially implements blueprint v3-api
Change-Id: I1116e8d8ebc73176223f4135168cc4ab5d904356
Adds support for basic image querying from the image server
rather than the Nova API. The Nova V3 API no longer supports
image querying directly, but in order to support convenience
functions such as specifying images by name rather than ID,
it is necessary to have some basic image query support.
image delete and image meta manipulation is no longer supported
by the client as these features can be accessed directly through
the glance client
Partially implements blueprint v3-api
Change-Id: I9050845d631e9dfc2e110327221d154b8924cd65
Adds support and tests for the os-agents extension
for the Nova V3 API
Partially implements blueprint v3-api
Change-Id: I53f8a1cbab6f4dee10fb823bc51ae90baa97fa7a
The first part of adding flavor support for the Nova V3 API (support
for flavor-access API calls is still to come).
Restructures v1_1 testcases so as much as possible so they can be
reused for the V3 version of the tests. If it looks too ugly an
alternative would be to just cut and paste the fakes and test
from v1_1 to v3, which is simpler to understand but comes at the
cost of duplicated code. The upside though is it would be much
easier to remove v1_1/v2 support in the future.
Partially implements blueprint v3-api
Change-Id: Ic7cb3c43db02c07d37aea2675b310aaa50639c40
Set the default service type when talking to the Nova V3 API to
computev3 rather than compute. Although it is rather ugly to have
a different service type for a different version of a service,
this is necessary for the medium term because traditionally the
compute service endpoint has pointed to the V2 API rather than
the root and then version discovery done.
This change allows progression of the V3 API support in
novaclient and although devstack too currently points computev3
directly to the V3 API, the intent is to change this to point to
the root and implement version discovery during the Icehouse
development cycle.
Longer term when the V2 API support is eventually removed we can
reclaim the 'compute' service type and point it to the root.
Partially implements blueprint v3-api
Change-Id: If5d6a0d8af037cde7bf253d71aac2823b89f8066
Some of the host code required changes to work with the v3 API.
This change adds a v3-compatible HostManager that inherits from
the 1_1 HostManager to make use of the functions that didn't
need to change.
bp v3-api
Change-Id: I3ef7ab4619d49c20ab1bdeb1185ad28b411d37a1
Client.__init__ method used self.os_cache variable in an internal method call
though this variable had not been initialized earlier.
In addition, unittests added for full coverage of client v3.
Change-Id: I421f82932b65f137932d933e04d42064bec0d08d
The v3 code references v1_1 code because it's a straight-across
copy. Remove those in preparation for adding the actual v3
versions.
bp v3-api
Change-Id: I359c6c5fc70dd91fa418802cc8048e186f5d09a4
Create the v3 directory and populate it with some of the basic
files from v2 that will be needed. These files are straight
copies so that v3-specific changes will be easier to see in
subsequent changes.
Extensions will be added individually in future changes.
bp v3-api
Change-Id: I9538c70ccc6fb001ce2fd43ccfd41870f247c67e
Andrey Kurilin