The new auto-pulled requirements files exposed
python 3 compat issues in a number of modules.
We added these to tox.ini ignore temporarily,
this change updates the print routines in bin/cinder
and removes the debug cruft that was in the unit tests.
Will update requirements and test-requirements
appropriately in a follow up patch.
Change-Id: I76ea24f4dc1f61c4f8a1d202b0554c90daf2c9cc
A bug in PBR levels less than 0.5.10 causes the
/usr/lib/python2.X/site-packages/cinder/db/sqlalchemy/migrate_repo/migrate.cfg
file to not be properly installed. This causes 'cinder-manage db sync'
to fail due to the missing file.
This change sets the required PBR level to >=0.5.10,<0.6 to avoid the problem.
In the case that user already has a 0.5.X level of PBR installed that is less
than 0.5.10 it should be updated rather than encountering issues as our
test system did.
Change-Id: I532158277a4acbb2f8cb75d03c91097e6d7e0312
fixes: bug 1182203
rtslib is AGPL, so cinder-rtstool is defacto AGPL by importing it.
Remove cinder-rtstool from the OpenStack repository.
Fixes bug #1157091
Change-Id: I30c9ee19d43107fa7f2e5e65d69049b8d69d2bdf
Changes:
- Added cinder-backup to scripts in setup.py
- Added service_name to backup manager __init__
- Switched backup manager to using oslo.config
- Modified cinder-backup to use ProcessLauncher
Fixes bug: 1131147
Change-Id: I9b02d64def4ee892e9cfde4b4bcd50e5f9f9b707
The cfg API is now available via the oslo-config library, so switch to
it and remove the copied-and-pasted version.
Add the 2013.1b3 tarball to tools/pip-requires - this will be changed
to 'oslo-config>=2013.1' when oslo-config is published to pypi. This
will happen in time for grizzly final.
Add dependency_links to setup.py so that oslo-config can be installed
from the tarball URL specified in pip-requires.
Remove the 'deps = pep8==1.3.3' from tox.ini as it means all the other
deps get installed with easy_install which can't install oslo-config
from the URL.
Retain dummy cfg.py file until keystoneclient middleware has been
updated (I18c450174277c8e2d15ed93879da6cd92074c27a).
Change-Id: I4815aeb8a9341a31a250e920157f15ee15cfc5bc
This patch enables LIO as an iSCSI backend for Cinder, using
python-rtslib.
To enable, set "iscsi_helper = lioadm" in cinder.conf.
This requires python-rtslib 2.1.fb27, which is available from pip.
Implements blueprint lio-iscsi-support
DocImpact
Change-Id: Ifb23de65f26a40997afd6148a1d0be39bcc8d196
Due to the fact that certain volume back-ends cannot easily report
simple total_capacity_gb/free_capacity_gb for their internal
implementation complexity, scheduler is updated to let those back-ends
who report unclear capacity pass capacity filter, thus there is chance
create_volume() request would fail. In a more general case, when a
volume back-end failed to serve create_volume request for whatever reason
it'd be good that we have a mechanism to 'retry' the request.
So the idea is when volume manager catches the exception from
driver.create_volume() call, it checks if the request is allowed to be
rescheduled (requests that are not: clone volume and create volume from
snapshot while 'snapshot_same_host' option is true), it composes a new
request back to scheduler with additional information to mark this specific
back-end has been tried (so that scheduler may choose to skip this back-end
if needed). Scheduler is (filter scheduler only, simple and chance
scheduler is not supported) is updated as well so that it only retry
scheduler_max_attempts times. In order to skip/rule out previously tried
back-ends in next schedule task, a new RetryFilter is added.
Changes:
1) volume RPC API create_volume() is updated with new parameters
to save original request information in case rescheduling is needed.
This bumps volume RPC API to 1.4.
2) implementation of create_volume() method in volume API is
refactored in order to distinguish if a request is allowed to
do reschedule (i.e. currently create volume from source volume
bypasses scheduler, not rescheduling is allowed).
3) add reschedule functionality in create_volume() of volume
manager so that it's able to send the request back to scheduler.
4) add schedule_max_attempts config option in scheduler/driver.py
5) add RetryFitler
6) change scheduler_driver default option to FilterScheduler
Change-Id: Ia46b5eb4dc033d73734b6aea82ada34ba5731075
In order to do more sophisticated scheduling (e.g. schedule based on volume
type), filter scheduler is introduced. Several changes are made to make this
possible, some of them are similar to the counterpart in Nova:
- add HostState class to host_manager in order to store volume capabilities
- implement get_volume_stats() method of iSCSIDriver as an example to
demonstrate how volume backend driver reports capabilities as well as status
- add scheduler_options.py and 'scheduler_json_config_location' flag to be
allow loading json configuration file for scheduler at run time
- port common filters/weights from oslo
- add capacity weigher (scheduler/weights/capacity.py) for picking up
target volume backend by weighing free capacity of the host. The default
behavior is to spread volumes across hosts; by changing the
'capacity_weight_multiplier' to negative number, volume placing behavior will
become stacking.
- add capacity filter which filters those hosts have insufficient storage space
to serve the request.
- add 'reserved_percentage' config option to indicate how much space is
reserved. Capacity reservation is needed when volume resize is enabled.
- add 'publish_service_capabilities()' method to volume RPC API to allow
scheduler to have volume service report capabilities. This bumps volume RPC
API to version 1.2
- remove 'volume_force_update_capabilities' config option, volume status will be
report to scheduler in every checking.
The implication of this change to storage/backend driver developer:
- implementation of get_volume_stats() of the driver is now a *MUST*, filter
scheduler heavily relies on the status/capabilities reported by backend driver
to makeplacement decision. To ensure Cinder works seamlessly on the storage
system, driver should at least report following capabilities/status:
----------------------+---------------------------+---------------------------
Capability/Status | Description | Example
----------------------+---------------------------+---------------------------
'volume_backend_name'| back-end name, string | 'Example_Storage_Backend'
----------------------+---------------------------+---------------------------
'vendor_name' | vendor name, string | 'OpenStackCinder'
----------------------+---------------------------+---------------------------
'driver_version' | version, string | '1.0a'
----------------------+---------------------------+---------------------------
'storage_protocol' | supported protocols, | 'iSCSI', 'RBD', 'FC', 'NFS'
| string or list of strings | ['iSCSI', 'NFS', 'FC']
----------------------+---------------------------+---------------------------
'total_capacity_gb' | capacity in GB, integer | 102400
----------------------+---------------------------+---------------------------
'free_capacity_gb' | available capacity in GB, | 1000
| integer |
----------------------+---------------------------+---------------------------
'reserved_percentage' | reserved space in | 0, 10
| percentage, integer |
----------------------+---------------------------+---------------------------
The implication of this change to Cinder administrator:
- the default setting for filter scheduler should work well with the benefits
of:
* being able to fully utilize capacity of backends (driver now has to report
actul total space and space utilization and scheduler uses these info) not
limited by the 'max_gigabytes' config option any more;
* being able to choose placement policy between spreading & stacking for
volume creation (by modifying the 'capacity_weight_multiplier' in
CapacityWeigher)
- with filter scheduler, Cinder is now able to utilize the advanced features/
capabilities provided by different storage back-ends via: defining different
volume types with proper extra_specs. Volume types can be considered as sets
of back-end capabilities requirement.
For example, a volume type which has 'storage_protocol':'FC' key/value pair
definition in its extra_spec can only be served by those back-ends who report
they support FiberChannel protocol. Another example is volume type has 'QoS'
requirement can only be served by back-ends support QoS.
Note/TODO:
* Currently scheduler makes its decision based on the status and capabilities
information reported by volume nodes, and these information is stored in memory
of scheduler process. More sophisticated way may be add on table in DB to
record status/capabilities of all volume nodes, like Nova does for compute nodes.
implement bp volume-type-scheduler
DocImpact
Change-Id: I296b3727db8de0d4cf085fac602d122a7b474842
In order to do more sophisticated scheduling (e.g. schedule based on volume
type), filter scheduler is introduced. Several changes are made to make this
possible, some of them are similar to the counterpart in Nova:
- add HostState class to host_manager in order to store volume capabilities
- implement get_volume_stats() method of iSCSIDriver as an example to
demonstrate how volume backend driver reports capabilities as well as status
- add scheduler_options.py and 'scheduler_json_config_location' flag to be
allow loading json configuration file for scheduler at run time
- port common filters/weights from oslo
- add capacity weigher (scheduler/weights/capacity.py) for picking up
target volume backend by weighing free capacity of the host. The default
behavior is to spread volumes across hosts; by changing the
'capacity_weight_multiplier' to negative number, volume placing behavior will
become stacking.
- add capacity filter which filters those hosts have insufficient storage space
to serve the request.
- add 'reserved_percentage' config option to indicate how much space is
reserved. Capacity reservation is needed when volume resize is enabled.
- change default scheduler to 'filter.FilterScheduler'.
- add 'publish_service_capabilities()' method to volume RPC API to allow
scheduler to have volume service report capabilities. This bumps volume RPC
API to version 1.2
- remove 'volume_force_update_capabilities' config option, volume status will be
report to scheduler in every checking.
The implication of this change to storage/backend driver developer:
- implementation of get_volume_stats() of the driver is now a *MUST*, filter
scheduler heavily relies on the status/capabilities reported by backend driver
to makeplacement decision. To ensure Cinder works seamlessly on the storage
system, driver should at least report following capabilities/status:
----------------------+---------------------------+---------------------------
Capability/Status | Description | Example
----------------------+---------------------------+---------------------------
'volume_backend_name'| back-end name, string | 'Example_Storage_Backend'
----------------------+---------------------------+---------------------------
'vendor_name' | vendor name, string | 'OpenStackCinder'
----------------------+---------------------------+---------------------------
'driver_version' | version, string | '1.0a'
----------------------+---------------------------+---------------------------
'storage_protocol' | supported protocols, | 'iSCSI', 'RBD', 'FC', 'NFS'
| string or list of strings | ['iSCSI', 'NFS', 'FC']
----------------------+---------------------------+---------------------------
'total_capacity_gb' | capacity in GB, integer | 102400
----------------------+---------------------------+---------------------------
'free_capacity_gb' | available capacity in GB, | 1000
| integer |
----------------------+---------------------------+---------------------------
'reserved_percentage' | reserved space in | 0, 10
| percentage, integer |
----------------------+---------------------------+---------------------------
The implication of this change to Cinder administrator:
- the default setting for filter scheduler should work well with the benefits
of:
* being able to fully utilize capacity of backends (driver now has to report
actul total space and space utilization and scheduler uses these info) not
limited by the 'max_gigabytes' config option any more;
* being able to choose placement policy between spreading & stacking for
volume creation (by modifying the 'capacity_weight_multiplier' in
CapacityWeigher)
- with filter scheduler, Cinder is now able to utilize the advanced features/
capabilities provided by different storage back-ends via: defining different
volume types with proper extra_specs. Volume types can be considered as sets
of back-end capabilities requirement.
For example, a volume type which has 'storage_protocol':'FC' key/value pair
definition in its extra_spec can only be served by those back-ends who report
they support FiberChannel protocol. Another example is volume type has 'QoS'
requirement can only be served by back-ends support QoS.
Note/TODO:
* Currently scheduler makes its decision based on the status and capabilities
information reported by volume nodes, and these information is stored in memory
of scheduler process. More sophisticated way may be add on table in DB to
record status/capabilities of all volume nodes, like Nova does for compute nodes.
implement bp volume-type-scheduler
DocImpact
Change-Id: I8b5305bce3b24bcc85365037356a8f36d0107133
Along with moving to pep8 1.3.3, we also want to standardize
on what we ignore. This patch get's us most of the way there
by setting the ignore list to:
N4,E125, E126, E711,E712.
Almost all changes made here are white-space/indentation changes.
The removal of Hacking N4 errors from the ignore list will
be handled in a seperate patch.
Change-Id: If45f156600485d23769449018590f60b4f69b0c5
Add classifiers so we can eventually register the project
on PyPI to reserve the name, even though we won't release
packages there.
Change-Id: I11fa429d34301ba9a1ec9a543f88d57eb3ac56bb
Signed-off-by: Doug Hellmann <doug.hellmann@dreamhost.com>
setup.py still has references to nova/compute and was missing some
requires statements, and more importantly didn't hvae the install_requires.
Also, tools/pip-requires needed lxml versions set, as well as
added the missing setuptools_git entry.
This was exposed when trying to run Grenade as the requires.txt
file was never generated.
Fixes bug #1055693
Change-Id: Iaf9669d66e89507989ef3fde630dc2b488a97cfc
Renames clear_rabbit_queues and volume-usuage-audit binaries
so that they are prefixed with 'cinder-'.
As part of this change the clear_rabbit_queues binary was changed
to use dashes instead of underscores for consistency with the rest
of the cinder binaries.
Fixes LP Bug #1044386.
Change-Id: I7692a543cc67af2d342a64b84626de38c0a64f81
adding the volume notifications
added unit tests for notifications
added context for notify with rabbit
blueprint cinder-notifications
Change-Id: I5aef1e718eebb9a61e0670d524fcd5f438dee016
