325001045c
As per the community goal of migrating the policy file format from JSON to YAML[1], we need to do two things: 1. Change the default value of '[oslo_policy] policy_file'' config option from 'policy.json' to 'policy.yaml' with upgrade checks. 2. Deprecate the JSON formatted policy file on project side via warning in doc and format releasenotes. 1st item if already done by cinder in Stein so this commit only cover the 2nd item. Since oslo.policy 3.6.0, by default oslo policy will fallback to existing policy.json file to give operator some time to migrate it to new default policy.yaml. But cinder already changed the default value to policy.yaml long back since Stein so no need to fallback to default JSON file. To do that it disable this fallback via flag to oslo.policy. Also convert the tests/unit/policy.json to policy.yaml file. Additionally, made some corrections to outdated documentation when removing references to a "policy.json" file. [1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html Co-Authored-By: Brian Rosmaita <rosmaita.fossdev@gmail.com> Change-Id: Iaf8a454e60d1e4b66981b61175f89203cc15e439
95 lines
4.3 KiB
ReStructuredText
95 lines
4.3 KiB
ReStructuredText
=========================================
|
|
Introduction to the Block Storage service
|
|
=========================================
|
|
|
|
The Block Storage service provides persistent block storage
|
|
resources that Compute instances can consume. This includes
|
|
secondary attached storage similar to the Amazon Elastic Block Storage
|
|
(EBS) offering. In addition, you can write images to a Block Storage
|
|
device for Compute to use as a bootable persistent instance.
|
|
|
|
The Block Storage service differs slightly from the Amazon EBS offering.
|
|
The Block Storage service does not provide a shared storage solution
|
|
like NFS. With the Block Storage service, you can attach a device to
|
|
only one instance.
|
|
|
|
The Block Storage service provides:
|
|
|
|
- ``cinder-api`` - a WSGI app that authenticates and routes requests
|
|
throughout the Block Storage service. It supports the OpenStack APIs
|
|
only, although there is a translation that can be done through
|
|
Compute's EC2 interface, which calls in to the Block Storage client.
|
|
|
|
- ``cinder-scheduler`` - schedules and routes requests to the appropriate
|
|
volume service. Depending upon your configuration, this may be simple
|
|
round-robin scheduling to the running volume services, or it can be
|
|
more sophisticated through the use of the Filter Scheduler. The
|
|
Filter Scheduler is the default and enables filters on things like
|
|
Capacity, Availability Zone, Volume Types, and Capabilities as well
|
|
as custom filters.
|
|
|
|
- ``cinder-volume`` - manages Block Storage devices, specifically the
|
|
back-end devices themselves.
|
|
|
|
- ``cinder-backup`` - provides a means to back up a Block Storage volume to
|
|
OpenStack Object Storage (swift).
|
|
|
|
The Block Storage service contains the following components:
|
|
|
|
- **Back-end Storage Devices** - the Block Storage service requires some
|
|
form of back-end storage that the service is built on. The default
|
|
implementation is to use LVM on a local volume group named
|
|
"cinder-volumes." In addition to the base driver implementation, the
|
|
Block Storage service also provides the means to add support for
|
|
other storage devices to be utilized such as external Raid Arrays or
|
|
other storage appliances. These back-end storage devices may have
|
|
custom block sizes when using KVM or QEMU as the hypervisor.
|
|
|
|
- **Users and Tenants (Projects)** - the Block Storage service can be
|
|
used by many different cloud computing consumers or customers
|
|
(tenants on a shared system), using role-based access assignments.
|
|
Roles control the actions that a user is allowed to perform. In the
|
|
default configuration, most actions do not require a particular role,
|
|
but this can be configured by the system administrator in the
|
|
cinder policy file that maintains the rules.
|
|
|
|
.. note::
|
|
For more information about configuring cinder policies, see
|
|
:ref:`policy-configuration`.
|
|
|
|
A user's access to particular volumes is limited by tenant, but the user
|
|
name and password are assigned per user. Key pairs granting access to a
|
|
volume are enabled per user, but quotas to control resource consumption
|
|
across available hardware resources are per tenant.
|
|
|
|
For tenants, quota controls are available to limit:
|
|
|
|
- The number of volumes that can be created.
|
|
|
|
- The number of snapshots that can be created.
|
|
|
|
- The total number of GBs allowed per tenant (shared between
|
|
snapshots and volumes).
|
|
|
|
You can revise the default quota values with the Block Storage CLI,
|
|
so the limits placed by quotas are editable by admin users.
|
|
|
|
- **Volumes, Snapshots, and Backups** - the basic resources offered by
|
|
the Block Storage service are volumes and snapshots which are derived
|
|
from volumes and volume backups:
|
|
|
|
- **Volumes** - allocated block storage resources that can be
|
|
attached to instances as secondary storage or they can be used as
|
|
the root store to boot instances. Volumes are persistent R/W block
|
|
storage devices most commonly attached to the compute node through
|
|
iSCSI.
|
|
|
|
- **Snapshots** - a read-only point in time copy of a volume. The
|
|
snapshot can be created from a volume that is currently in use
|
|
(through the use of ``--force True``) or in an available state.
|
|
The snapshot can then be used to create a new volume through
|
|
create from snapshot.
|
|
|
|
- **Backups** - an archived copy of a volume currently stored in
|
|
Object Storage (swift).
|