Make cinderclient use volumev3 or volumev2 endpoints, before
falling back to the volume endpoint, otherwise Horizon is
trying to use the v1 API, and that doesn't work with the
"sort" parameter that we are using, resulting in an empty
volumes list.
Change-Id: Id03988d89000c4bc976090c68a41ee320b9d43f7
Closes-bug: #1700977
Cinder can now show asynchronous error messages that are related to a
volume. However, this requires microversions support.
This patch cleans up the version and endpoint selection logic too. For
compatibility with setups that don't follow good practices, it also
checks for a "volume" endpoint.
Change-Id: Ifdb7537b5208683bb0a81da9ac504d58beaedc89
Closes-Bug: 1352516
In addition to "available" volumes, those that are "in-use" can now be
backed up. Backing up "in-use" volumes requires setting the "force"
parameter in the cinder backup call.
Closes-Bug: 1686671
Change-Id: I8a11216be49313f710ce5874499f8d2efba91e73
attribute-level imports are not checked by hacking module now.
most noqa is used to disable warnings on attribute-level imports.
This commit drops noqa for this purpose.
After this, there are only 3 noqa under openstack_dashboard/ :)
Change-Id: I4a449802f5dbd6e44e4b8b5c378a555d47d9a99f
Cinder v2 support add or remove volume type access for the given
project since Kilo [1]. This patch add this feature to horizon.
At least cinderclient 1.2.0 is required to support volume type
access extension.
[1]:
https://specs.openstack.org/openstack/cinder-specs/specs/kilo/private-volume-types.html
Implements blueprint: volume-type-access
Change-Id: I323d47ab2aed13305b609e27f8f959f40988537d
The volume backup code is passing '' as a default container name,
which will cause cinder/swift to fail. If no container name is provided,
the default value of None will enable the auto creation of a container correctly.
Change-Id: I7813153c65652ce6e1a5ac03204a8738eefdc64e
Closes-Bug: #1658137
Since Horizon is going to be the first (or, one of the first)
OpenStack component using the new MongoDB driver, it won't be able to
retrieve traces made by other components using MongoDB driver (which
it should use because Ceilometer driver was too slow) for a
while. This means that Horizon itself is responsible for tracing the
rendering of its pages down to the layer where the flow of control
leaves Horizon domain. So, a lot of api wrappers in
openstack_dashboard.api are augmented with tracing decorator to
achieve this goal.
Co-Authored-By: Timur Sufiev <tsufiev@mirantis.com>
Implements-blueprint: openstack-profiler-at-developer-dashboard
Change-Id: Ib36692f0e9e68ed7fa0cd47919ba6581c9c8ab57
Cinder currently expose an api to let the users update the volumes
metadata so horizon should expose this functionality.
The metadata is filtered to remove image metadata attributes. There is
work in progress (in Cinder) that will expose the ability to
write-through image metadata to underlying images where appropriate.
Allowing setting of image properties in this UI would be confusing.
Change-Id: If721ac1c908df7651d630f6e7d36f2cc4d69f5da
Implements: blueprint ability-to-add-metadata-to-cinder-volumes-and-snapshots
Co-Authored-By: Santiago Baldassin <santiago.b.baldassin@intel.com>
Co-Authored-By: Pawel Skowron <pawel.skowron@intel.com>
Co-Authored-By: Bartosz Fic <bartosz.fic@intel.com>
Co-Authored-By: Pawel Koniszewski <pawel.koniszewski@intel.com>
Co-Authored-By: Michal Dulko <michal.dulko@intel.com>
Co-Authored-By: David Lyle <david.lyle@intel.com>
Co-Authored-By: Paul Karikh <pkarikh@mirantis.com>
cinder api (api/cinder.py) cinderclient returns an
UnashableKeyWarning for client api_version param.
This patch fixes the bug by removing the api_version param from the
memoized with request function.
Change-Id: I11f3ca8642fb746bd725f059f089f9b3900c6f66
Closes-Bug: #1606020
cinder api should memoize more persistanly on objects that do not
change when rendering each view, i.e. Supported extensions list
Implements blueprint: improve-horizon-caching
Change-Id: I3939f2a09b19cc2715738b8dbedc13606b2430dc
When accessing the snapshot object in Horizon codebase, we do not have
access to the metadata of the snapshot. This is because the
VolumeSnapshot object does not have metadata as a member. So added
'metadata' to the VolumeSnapshot object. The fix should provide access
to metadata.
Added test data and test cases for snapshot object with metadata.
Closes-Bug: 1542468
Change-Id: I4ae2e7a74d3ddbff8493b42f8f86c7002229cf8c
This extends the support for Cinder volume consistency groups.
This patch adds snapshot support for all volumes contained
within a consistency group.
Additional features includes the ability to create a new
consistency group from an existing consistency group
or consistency group snapshot. This will involve cloning
all volumes in the original CG.
To enable this feature, update "consistencygroup" items in
the cinder policy file (/etc/cinder/policy.json). The default
is that all consistencygroup actions are disabled.
Co-Authored-By: Brad Pokorny <brad_pokorny@symantec.com>
Change-Id: I2e2ae26369a23415bf58d6edac8d161d3a125dd6
Implements: blueprint cinder-consistency-groups
Currently, volume type is created default with public, if we want to
modify the volume type's access it should be changed to private.
This patch adds the is_public property when creating and updating
volume type.
Related blueprint: volume-type-access
Change-Id: I3c14fdf1c5835e71921245f4f9686841fbc380a5
Cinder has added support for creating and managing volume consistency
groups. This first patch adds this functionality into Horizon.
Subsequent patches will add features to utilize these consistency
groups - such as for creating snapshots.
Background/setup info:
This feature provides a Horizon interface to the Cinder consistency
groups (CG) API. CGs allow a user to group a set of volumes together,
and then perform actions on all of the volumes in one command.
For example:
- Create CG snapshot. This will pause all volume I/O and create a
snapshot for each volume in the CG at the same point in time.
- Create CG from another CG. This will clone a new set of volumes based
on the current state of all volumes in the original CG.
- Create CG from CG snapshot. This will clone new set of volumes based
on the saved state of all snapshots from the original CG snapshot.
This patch is limited to just creating consistency groups. A second
and final patch will add the snapshot features.
To run the patch, you will need to enable some consistency group
policies, which currently are defaulted to "none", which means they
are disabled.
The policies are set in /etc/cinder/policy.json - they need to be set
to the following:
"consistencygroup:create" : "rule:admin_or_owner",
"consistencygroup:delete": "rule:admin_or_owner",
"consistencygroup:update": "rule:admin_or_owner",
"consistencygroup:get": "rule:admin_or_owner",
"consistencygroup:get_all": "rule:admin_or_owner",
"consistencygroup:create_cgsnapshot" : "rule:admin_or_owner",
"consistencygroup:delete_cgsnapshot": "rule:admin_or_owner",
"consistencygroup:get_cgsnapshot": "rule:admin_or_owner",
"consistencygroup:get_all_cgsnapshots": "rule:admin_or_owner",
Once this is done, you will need to restart all 3 of the cinder
services in "screen -r" (c-api, c-sch, and c-vol).
The new panel is a tab named "Volume Consistency Groups" and is
located in "Project -> Volumes".
Co-Authored-By: Brad Pokorny <brad_pokorny@symantec.com>
Change-Id: I33ebe39e79d7c1d1dc7e741b4199bcb259b642d1
Partially-implements: blueprint cinder-consistency-groups
Volumes tabs should be enabled when volumev2 endpoint is registered.
Currently, Horizon considers no volume service is running if there
is no V1 endpoint, which doesn't make sense as Horizon no longer
supports the cinder V1 protocol.
Co-Authored-By: itxaka <itxaka@redhat.com>
Change-Id: I35d821eedb75f73f9330ed11f921694104eed0c6
Closes-Bug: 1415712
When listing all cinder volumes the user may not have
permissions to see the volume transfers.
This patch makes it so the call to transfer_list
is protected against Forbiden errir so the user can still
see the volume list.
Change-Id: I575ffebcd5084165e72f6e100ed43b4d3f358e98
Closes-Bug: #1541094
We were missing the lock_volume parameter, causing the call
to volume_migrate to always fail.
Change-Id: I8d2b5db9e2cb9551ac4bb47564b1f81c088d4ed3
Co-Authored-By: Dmitry Galkin
Closes-bug: #1533663
Do it for both Project (both Snapshots and Backups tabs) and Admin
(only Snapshots tab) dashboards.
To test: set 'Items Per Page' in the UI Settings page to a low number.
Change-Id: I9b16cf31c726055da0afad347e033f3918af3049
Closes-Bug: #1499664
Cinder v2 supports pagination.
Added to the volumes table for both admin and project.
Also fix the Cinder REST API to handle pagination (like Glance
REST API).
To test: set 'Items Per Page' in the UI Settings page to a low number.
Co-Authored-By: Cindy Lu <clu@us.ibm.com>
Co-Authored-By: Timur Sufiev <tsufiev@mirantis.com>
Change-Id: Ib1772d6e6214dc96a09ce32fb4d9f9fb79d161f0
Closes-Bug: #1316793
This patch adds support to horizon for volume type encryption
update.
The modifications are made to the Admin Volume Type table, and
add the Update Encryption action to the action column.
Implements: blueprint integration-with-cinder-volume-encryption
Change-Id: I7b6f1db60818a07feb64eaa464e64397ea477a7b
Currently when you try to delete a volume type (which is in use) Horizon
returns a generic message.
This patch includes in this message the text from the exception, resulting on
the following message:
'Error: Volume type '<vol_type>' is still in use.'
Change-Id: I9577127909dca70a4c45129bf5df7e11b6ab1c2f
Closes-bug: #1334523
Adding cinder services to create and update volumes and volume snapshots,
return Quality of Service and tenant absolute limits.
This is to support dependent patches that will create volumes for Images
from the angular panel for Images.
Co-Authored-By: Errol Pais<epais@thoughtworks.com>
Co-Authored-By: Nathan Zeplowitz<nzeplowi@thoughtworks.com>
Partially-Implements: blueprint angularize-images-table
Change-Id: I4c48c09a0f20f971588b1e920a555f12e7ed4498
This change makes it so the create volume screen selects the default
volume type (instead of the "No Volume Type" as the default).
Change-Id: I0fd0993adb422701f00ecfdfc81c737b7d1db794
Closes-bug: #1493433
Added the following features for admin volumes types
1. "Create Volume Type" dialog should include a description field.
2. The volume types table should include description column.
3. The volume types table name and description columns are in-line
editable.
4. The 'Edit Volume Type' action is added for the volume type. User should
be able to update volume type name and description.
Added the following features in project volumes
1. "Create Volume" dialog will have description for the selected volume
type when volume type select is available.
2. "No Volume type" will have some description as well.
Implements: blueprint volume-type-description
Change-Id: I7c8548756bcd3566873876bbc59f9b9c21d6846b
This is a very early cut at the REST API needed to
support the create instance wizard work.
Partially Implements: blueprint launch-instance-redesign
Co-Authored-By: Michael Hagedorn <mike.hagedorn@hp.com>
Co-Authored-By: Richard Jones <r1chardj0n3s@gmail.com>
Co-Authored-By: Travis Tripp <travis.tripp@hp.com>
Change-Id: I0c37474e81f5ee9893768974e47a20532c535b91
Manage will take an existing volume created outside of Openstack and
make it available. Unmanage will remove the visibility of a volume
within Openstack, but will not delete the actual volume.
Change-Id: I6df46f0944015833d1fb94611f9bf520ca8bca8b
Implements: blueprint add-manage-unmanage-volume
Although it is possible to see whether a volume is encrypted or not
encrypted (by viewing the "Encrypted" column of the volume), it is
not yet possible to view the encryption metadata for an encrypted
volume.
This patch adds a link to the "Yes" in the Encrypted column of the
volume, which displays an overview of the encryption metadata for
the volume when clicked. This encryption metadata includes cipher,
key size, provider, control location, and volume type name. Also
adds unit tests.
Change-Id: Ic57e64eb85b46e77ed03d86722523c316c873d18
Implements: blueprint view-volume-encryption-metadata
Cinder supports volume transfers, which are transfers of ownership from
one project to another. The normal flow is that a donor creates a volume
transfer, captures the resulting transfer id and secret authentication
key, and passes that information out of band to the recipient (such as
by email, text message, etc.). The recipient then accepts the transfer,
supplying the transfer id and authentication key. The ownership of the
volume is then transferred from the donor to the recipient, and the
volome is no longer visible to the donor.
It is important to know of some limitations about the cinder API for
volume transfers and their impact on the UI design.
1. When creating a volume transfer, you cannot specify who the intended
recipient will be, and anyone with the transfer ID and auth key can
claim the volume. Therefore there is no UI to prompt for a
recipient.
2. Current volume transfers are only visible to the donor; users in
other projects are unable to view these transfers. This makes it
pointless to create a project table to view and accept volume
transfers, since the current transfers are not visible. Instead, the
transfer information has been added to the volume details, which are
visible by the donor, and the volume state clearly reflects that a
transfer has been created. It it also impossible to present to the
recipient a pull-down list of transfers to accept.
3. The only time that the authorization key is visible to the donor is
in the response from the creation of the transfer; after creation it
is impossible for even the donor to recover it. Since the donor must
capture the transfer ID and authorization key in order to send it to
the recipient, an extra form was created to present this information
to the donor immediately after the transfer has been created. It is
not enough to put the information in a success message, since these
are typically only displayed for a small number of seconds before
they disappear.
Co-Authored-By: Gary W. Smith <gary.w.smith@hp.com>
Co-Authored-By: Julie Gravel <julie.gravel@hp.com>
Implements blueprint cinder-volume-transfer
Change-Id: I0134f90c93a8d804d2c87fe9713bcef9e1629d79
For Project=>Volumes, the edit panel will now allow
the user to set/unset the bootable flag.
Change-Id: Idf913b284f56d52b3bf9be4c716a7c041dd9b5bb
Implements: blueprint volume-bootable-flag
This patch adds support to horizon for volume type encryption
delete. The contents of this patch were originally a part of
a combined volume type encryption update and delete patch,
(https://review.openstack.org/#/c/72024/) but the delete
portion has been moved to this patch since the pieces do not
depend on each other.
The modifications are made to the Admin Volume Type table, and
add the Delete Encryption action to the action column. Unit
tests are also included.
Change-Id: Ide9109ca22a04b9121bc78eeea26be9ef2adbf97
Implements: blueprint integration-with-cinder-volume-encryption
This patch adds support to horizon for the volume type encryption
changes made in cinder (https://review.openstack.org/#/c/30974/) and
in python-cinderclient (https://review.openstack.org/#/c/39984/).
The modifications are made to the Volume Type table, and add the
Create Encryption action to the action column. Also, an Encryption
column is added, which includes a link to a summary of the encryption
information for the volume type.
Change-Id: I7f8e6396f8a1819ec6cb07f47ef6ba65832130c8
Implements: blueprint integration-with-cinder-volume-encryption
In some cases negative values can be returned for resources currently
in use. When this occurs, the project overview page fails with an
error 500 due to an OverflowError, "cannot convert float infinity to
integer". Handle this case more gracefully.
Change-Id: Id1ad16eafdde906dc74bfafc7f72ea8d3bdcdc8f
Closes-Bug: #1386687
Cinder API v1 was deprecated in Juno and is being removed in Kilo.
Implements: blueprint horizon-cinder-v2-preferred-version
Closes-Bug: 1376424
Change-Id: I9bbdf1753a06d33b441a85ff448f475545eafc80
Previously token values are logged as DEBUG level when a new client
object is instantiated. In other project and clients, token values
are now not logged and is output as *REDACTED* instead.
In Horizon these log lines do not have much meaning and
we can simply remove them.
Change-Id: I67617ac6424907574d79ec2a57b513a548e220d2
Closes-Bug: #1380642
This reverts commit ed586a0355fb99a5b1fbeadfc0625f0ceffe8b72.
The quota_class subcommand in python-novaclient was used to set default
quota values so it shouldn't have been removed. As now it is being
restored, the defaults quota panel is being restored too.
Related mailing list thread on the topic:
http://lists.openstack.org/pipermail/openstack-dev/2014-May/035383.html
Resolved merge conflicts by hand in:
openstack_dashboard/api/cinder.py
openstack_dashboard/dashboards/admin/info/tabs.py
openstack_dashboard/dashboards/admin/info/tests.py
Updated translatable segments to match refactors in
openstack_dashboard/dashboards/admin/defaults/workflows.py
openstack_dashboard/dashboards/admin/defaults/tables.py
Fixed most egregious post-merge styling errors in
openstack_dashboard/dashboards/admin/defaults/templates/defaults/index.html
(probably should have been separate, but I just couldn't let it out that way!)
Removed unrelated file that was allowed to be part of the original commit
doc/source/topics/settings.rst
Co-Authored-By: Doug Fish <drfish@us.ibm.com>
Change-Id: Ic4c4ecec843c7ea9afd0db36ce0eb15952da15b3
Partial-Bug: #1299517