Inclusion of a project_id in API URLs is now optional, and no longer
required. Removing the project_id requirement facilitates supporting
Secure RBAC's notion of system scope, in which an API method is not
associated with a specific project.
The API v3 routing is enhanced to provide duplicate routes for API
methods that traditionally required a project_id in the URL:
- The existing route for which a project_id is in the URL
- A new route for when the URL does not include a project_id
To test both routes and ensure there are no regresssions, the "API
samples" functional tests include a project_id in the URLs, and the
rest of the functional tests do not include the project_id. This is
handled by changing the 'noauth' WSGI middleware to no longer add the
project_id, and adding a new 'noauth_include_project_id' middleware
filter that implements the legacy behavior.
A new microversion V3.67 is introduced, but it only serves to inform
clients whether the project_id is optional or required. When an API
node supports mv 3.67, the project_id is optional in all API requests,
even when the request specifies a earlier microversion. See the spec
Ia44f199243be8f862520d7923007e7182b32f67d for more details on this
behavior.
Note: Much of the groundwork for this is based on manila's patch
I5127e150e8a71e621890f30dba6720b3932cf583.
DocImpact
APIImpact
Implements: blueprint project-id-optional-in-urls
Change-Id: I3729cbe1902ab4dc335451d13ed921ec236fb8fd
In this patch:
- adjusted VersionsController to return only v3
- removed cinder.api.v2.router
- adjustments to cinder.tests.unit.api.contrib to use /v3 only
- moved cinder.api.v2.snapshot_metadata (and tests) to cinder.api.v3
- moved cinder.api.v2.types (and view, tests) to cinder.api.v3
- updated versions response in api-ref
- removed unnecessary config option
- updated various sample config files
- removed experimental tempest-cinder-v2-api job
- updated some docs
- updated non-voting rally job config
Some cinder.api.v2 modules are left because the v3 classes depend on
them, but with the v2 router removed, these are unreachable via the
/v2 path.
Depends-on: https://review.opendev.org/c/openstack/rally-openstack/+/794891
(changes rally to use Block Storage API v3)
Depends-on: https://review.opendev.org/c/openstack/requirements/+/794894
(corrects regression in upper-constraint on Sphinx)
Change-Id: I2093d77db9beec7543c7524d2cd273e79dd5fd5d
This patch adds a feature by which we allow setting default volume types
for projects.
The following changes are made to achieve the feature:
1) Add 4 set of APIs, set, get, get_all, unset volume type
2) All policies (except get_all) default to system/domain/project admin
3) Preference order: project default, conf default
4) Logic to not allow deletion of default type
We validate set, get and unset APIs with keystone to verify a valid
project id is passed in the request and user has proper authorization
rights to show the project.
The policies are system/domain/project admin by default except get_all
policy which defaults to system admin.
Implements: Blueprint multiple-default-volume-types
Change-Id: Idcc949ed6adbaea0c2337fac83014998b81ff1f8
This is to remove the unncessary slash when the line doesn't
exceed the length of 79, to make the code more readable.
Change-Id: I3fea5d24692be8b8575379aff7b75a5479f314ef
Routing was set up to map to volume_transfers, but the cinder client and
other places expected it to be volume-transfer. The - is more correct
for API endpoints, and the client is currently in feature freeze, so
easiest way to correct this for this new feature is to update the
endpoint to the expected name.
Change-Id: Ib0002c441a2e860e8b74a4d9e6df890b398210f4
Closes-bug: #1785325
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This feature changes Cinder to transfer
snapshots with volumes at the same time by default.
If user doesn't want to transfer snapshots, they could use
a new optional argument '--no-snapshots' after microversion 3.55.
And we also introduce the new V3 api 'v3/volume_transfers'
to move this API out of contrib into Cinder V3 API.
The cinderclient patch: https://review.openstack.org/#/c/577611/
Change-Id: If848d131e5edcdb77d0b3c2ca45a99c4d5e14d1e
Implements: blueprint transfer-snps-with-vols
"cinder absolute-limits" command supports <tenant_id> filter,
But server side doesn't, this patch added the support for server
side.
APIImpact
Closes-bug: #1668416
Change-Id: Ib31ab87d0954c2bedf55c6d71623b2c7d07b5fa7
Replaces the original patch:
https://review.openstack.org/#/c/387712/
Use the python-cinderclient WIP:
https://review.openstack.org/#/c/387716/
Here's what you can do currently:
`cinder attachment-create <volume-uuid>`
Currently only tested/implemented the reserve piece
Will create an attachment object, set volume to a
status of 'reserved'
`cinder attachment-list`
Simple list output of attachments
`cinder attachment-show <attachment-uuid>`
Detailed list of specified attachment
`cinder attachment-delete <attachment-uuid>`
Removes an attachment
Change-Id: Ie15233c99d91de67279b56d27a5508c5ea98d769
Now that we support having multiple c-vol services using the same
storage backend under one cluster, they no longer clean all resources
from the backend with ongoing statuses in the DB, only those from their
own host because those are failed operations that were left "in the air"
when the service was stopped. So we need a way to trigger the cleanup
of resources that were being processed by another c-vol service that
failed in the same cluster.
This patch adds a new API endpoint (/workers/cleanup) that will trigger
cleanup for c-vol services as microversion 3.19.
The cleanup will be performed by other services that share the same
cluster, so at least one of them must be up to be able to do the
cleanup.
Cleanup cannot be triggered during a cloud upgrade, but a restarted
service will still cleanup it's own resources during an upgrade.
If no arguments are provided cleanup will try to issue a clean message
for all nodes that are down, but we can restrict which nodes we want to
be cleaned using parameters `service_id`, `cluster_name`, `host`,
`binary`, and `disabled`.
Cleaning specific resources is also possible using `resource_type` and
`resource_id` parameters.
We can even force cleanup on nodes that are up with `is_up`, but that's
not recommended and should only used if you know what you are doing.
For example if you know a specific cinder-volume is down even though
it's still not being reported as down when listing the services and you
know the cluster has at least another service to do the cleanup.
API will return a dictionary with 2 lists, one with services that have
been issued a cleanup request (`cleaning` key) and another list with
services that cannot be cleaned right now because there is no
alternative service to do the cleanup in that cluster (`unavailable`
key).
Data returned for each service element in these two lists consist of the
`id`, `host`, `binary`, and `cluster_name`. These are not the services
that will be performing the cleanup, but the services that will be
cleaned up or couldn't be cleaned up.
Specs: https://specs.openstack.org/openstack/cinder-specs/specs/newton/ha-aa-cleanup.html
APIImpact: New /workers/cleanup entry
Implements: blueprint cinder-volume-active-active-support
Change-Id: If336b6569b171846954ed6eb73f5a4314c6c7e2e
Currently the administrator could only reset the group snapshot
status by db operation, this change intends to add new admin
action to achieve this.
The patch list:
1. group API(https://review.openstack.org/#/c/389091/).
2. group snapshot API(this).
3. cinder client(https://review.openstack.org/390169/).
4. documentation(https://review.openstack.org/#/c/395464/).
APIImpact
DocImpact
Partial-Implements: blueprint reset-cg-and-cgs-status
Change-Id: I9e3a26950c435038cf40bea4b27aea1bd5049e95
Deleting multiple volume metadata keys with a single request to
improve performance. This patch uses etags to avoid the lost update
problem with volume metadata. To inject the response's `Etag` header
the index method returns webob.Response object with this tag.
APIImpact
Related blueprint: delete-multiple-metadata-keys
Change-Id: I575635258c10f299181b8e4cdb51a7ad1f1be764
This is the fifth patch that implements the generic-volume-group
bluerpint. It adds APIs for group snapshots and create group
from source.
This patch depends on the fourth patch which implements group
snapshots support in the volume manager:
https://review.openstack.org/#/c/361376/
Client side patch is here:
https://review.openstack.org/#/c/329770/
Current microversion is 3.14. The following CLI's are supported:
cinder --os-volume-api-version 3.14 group-create-from-src
--name my_group --group-snapshot <group snapshot uuid>
cinder --os-volume-api-version 3.14 group-create-from-src
--name my_group --source-group <source group uuid>
cinder --os-volume-api-version 3.14 group-snapshot-create
--name <name> <group uuid>
cinder --os-volume-api-version 3.14 group-snapshot-list
cinder --os-volume-api-version 3.14 group-snapshot-show
<group snapshot uuid>
cinder --os-volume-api-version 3.14 group-snapshot-delete
<group snapshot uuid>
APIImpact
DocImpact
Partial-Implements: blueprint generic-volume-group
Change-Id: I2e628968afcf058113e1f1aeb851570c7f0f3a08
This is the second patch that implements the generic-volume-group
bluerpint. It adds the groups table and introduces create/delete/
update/list/show APIs for groups.
It depends on the first patch which adds group types and group specs:
https://review.openstack.org/#/c/320165/
Client side patch is here:
https://review.openstack.org/#/c/322627/
Current microversion is 3.13. The following CLI's are supported:
cinder --os-volume-api-version 3.13 group-create --name my_group
<group type uuid> <volume type uuid>
cinder --os-volume-api-version 3.13 group-list
cinder --os-volume-api-version 3.13 create --group-id <group uuid>
--volume-type <volume type uuid> <size>
cinder --os-volume-api-version 3.13 group-update <group uuid>
--name new_name description new_description
--add-volumes <uuid of volume to add>
--remove-volumes <uuid of volume to remove>
cinder --os-volume-api-version 3.13 group-show <group uuid>
cinder --os-volume-api-version 3.13 group-delete
--delete-volumes <group uuid>
APIImpact
DocImpact
Change-Id: I35157439071786872bc9976741c4ef75698f7cb7
Partial-Implements: blueprint generic-volume-group
Add a new API to display volumes summary with total number of volumes
and total size in GB (total_size: 500 and total_count: 20).
DocImpact
APIImpact
Partially-Implements: blueprint display-volumes-summary-details
Co-Authored-By: MR Swami Reddy <swamireddy@gmail.com>
Change-Id: I0117a233afbd834a165ade9e1358f8dd38fbcfac
This patch adds support for group types and group specs.
This is the first patch to implement the blueprint
generic-volume-group.
The client side patch is here:
https://review.openstack.org/#/c/320157/
Current microversion is 3.11. The following CLI's are supported.
cinder --os-volume-api-version 3.11 group-type-create my_test_group
cinder --os-volume-api-version 3.11 group-type-list
cinder --os-volume-api-version 3.11 group-type-show my_test_group
cinder --os-volume-api-version 3.11 group-type-key my_test_group
set test_key=test_val
cinder --os-volume-api-version 3.11 group-specs-list
cinder --os-volume-api-version 3.11 group-type-key my_test_group
unset test_key
cinder --os-volume-api-version 3.11 group-type-update <group type uuid>
--name "new_group" --description "my group type"
cinder --os-volume-api-version 3.11 group-type-delete new_group
APIImpact
DocImpact
Change-Id: I38b938782e0c3b2df624f975bd07e0b81684c888
Partial-Implements: blueprint generic-volume-group
Add update interface so that users can update
name and description of a backup.
This new API endpoint is added in microversion 3.9.
APIImpact
Add PUT to /backups/<id>.
DocImpact
Change-Id: If592b53c7e1dcdc36dbcaa89425b8e44a51684c3
Create routes for the resources in the volume_manage and snapshot_manage
extensions in v3, and bump the microversion.
APIImpact
DocImpact
Implements: blueprint list-manage-existing
Change-Id: Ia0df241a43f41cac4248efffc0b9828032daf63a
This patch adds new API /cluster that allows summary and detailed
listings, show and update operations.
It also updates service listings to return cluster_name for each
service.
DocImpact: 3 new policies have been added for cluster, "get", "get_all" and
"update".
APIImpact: Return cluster_name in service listings and add /cluster endpoint.
Specs: https://review.openstack.org/327283
Implements: blueprint cinder-volume-active-active-support
Change-Id: If1ef3a80900ca6d117bf854ad3de142d93694adf
The consisgroup list/show etc interfaces are blocked in V3 API,
this patch is to fix it.
Change-Id: I428a661a12d1020ed844f55021a94bbf61c79169
Closes-Bug: #1597223
This change allow API user to remove the consistency group name
or description information.
If user use the `cinder consisgroup-update consisgroup-id --name ''`
or `cinder consisgroup-update consisgroup-id --description ''`
to update the consisgroup's name or description information,
the consisgroup's name or description information will be removed.
APIImpact
Change-Id: I0d661775994d6de580f8788397f0e91e90148edd
Closes-Bug: #1572986
In some modules the global LOG is not used any more. And the import
of logging is not used. This patch removes the unused logging import
and LOG vars.
Co-Authored-By: ChangBo Guo(gcb) <eric.guo@easystack.cn>
Change-Id: Ia72f99688ce00aeecca9239f9ef123611259a2fa
This patch implements basic user messages with the following APIs.
GET /messages
GET /messages/<message_id>
DELETE /messages/<message_id>
Implements : blueprint summarymessage
Co-Authored-By: Alex Meade <mr.alex.meade@gmail.com>
Co-Authored-By: Sheel Rana <ranasheel2000@gmail.com>
Change-Id: Id8a4a700c1159be24b15056f401a2ea77804d0a0
Currently cinder treats all non zero values passed to it
as True for bootable filter in volume GET call.
For ex, if bootable=invalid, it converts it into True being
bootable as boolean value in db table 'volume'.
Need to update filtering functionality in cinder to address
'True' and 'False' values separately and raise exception if
anything than True/False/true/false/0/1 is passed in this filter.
But as this will change the API behavior, microversioning is done
for this fix.
Closes-Bug: #1551535
Change-Id: Idd57014c1504eb4fc9ea0eabe894d2000ea9c364
Many changes to the Cinder REST API require changes to the consumers of the API.
For example, If we need to add a required parameter to a method that is called
by Nova, we'd need both the Nova calling code and the cinderclient that
Nova uses to change. But newer Cinder versions with the change must work with
older Nova versions, and there is no mechanism for this at the moment. Adding
microversions will solve this problem.
With microversions, the highest supported version will be negotiated by a field
in the HTTP header that is sent to the Cinder API. In the case where the field
'versions' is not sent (i.e. clients and scripts that pre-date this change),
then the lowest supported version would be used. In order to ensure that the
API consumer is explicitly asking for a microversioned API, a new endpoint v3
is added, which is identical to API version v2. This means that our new
Cinder API v3 would be the default, and consumers of the API that wished to
use a newer version could do so by using that endpoint and a microversion in
the HTTP header.
New tests for microversioned API features on endpoint /v3 should be added to
cinder/tests/unit/api/v3/ directory. Existing functionality will be tested via
the .../v2/ unit tests.
DocImpact
APIImpact
Implements: https://blueprints.launchpad.net/cinder/+spec/cinder-api-microversions
Change-Id: I48cdbbc900c2805e59ee9aebc3b1c64aed3212ae
Alan Bishop