We cannot run py34 unit tests without python3-dev, but we
also cannot add this to test-requirements.txt. The best we
can do is add the issue to the devref/unit_tests.rst to help
people find and fix the issue.
Change-Id: I5ff3fef979ca35f2fc4c1c512382f338f586ce51
Closes-Bug: #1563533
This is just for upstream developers, docs for operators should follow.
Related-Blueprint: rpc-object-compatibility
Change-Id: I7f9c7dc1d76f5d32c45e00a9e4da37323d927d3a
According to API working group guidelines:
https://review.openstack.org/#/c/243414
microversion headers should be of the form:
OpenStack-API-Version: [SERVICE_TYPE] 2.114
i.e OpenStack-API-Version: volume 3.22
Two extra headers are always returned in the response:
OpenStack-API-Version: [SERVICE_TYPE] version_number
Vary: OpenStack-API-Version
note: Servers must be prepared to deal with multiple
OpenStack-API-Version headers. This could happen when a client
designed to address multiple services always sends the headers it
thinks it needs. Most Python frameworks will handle this by setting
the value of the header to the values of all matching headers,
joined by a ',' (comma). For example ``compute 2.11,identity
2.114``.
Closes-Bug: #1551941
Change-Id: I658e54966c390b41e3b551dd9827606c2e013511
Doesn't do much good to add a doc if you never add it
to the index and remove spurious headers that cause it
to not publish.
This patch fixes those problems.
Change-Id: I5c1906a30539e7223f5cee8ce14a013005fe004d
This is something that confuses folks and isn't centrally
located. So... add it to the devref docs and hope that
developers read it.
There's tons of detail we can add in the future of course,
but this at least clears up some of the common misconceptions
that exist currently.
Change-Id: Ic5fb8da06d18fac3369a91a525accc75c1d28100
This focuses the replication work on a specific use case,
and eliminates some of the ambiguity in earlier versions.
Additionally this implementation addresses needs for
devices that do replication based on the whole backend-device
or on Pools.
Use case:
DR scenario, where a storage device is rendered inoperable.
This implementation allows the preservation of user data
for those volumes that are of type replication-enabled.
The goal is NOT to make failures completely transparent
but instead to preserve data access while an Admin tries
to rebuild/recover his/her cloud.
It's very important to note that we're no longer interested in
dealing with replication in Cinder at a Volume level. The concept
of have "some" volumes failover, and "others" left behind, proved
to not only be overly complex and difficult to implement, but we
never identified a concrete use-case where one would use failover
in a scenario where some volumes would stay and be accessible on
a primary but other may be moved and accessed via a secondary.
In this model, it's host/backend based. So when you failover,
you're failing over an entire backend. We heavily leverage
existing resources, specifically services, and capabilities.
Implements: blueprint replication-update
Change-Id: If862bcd18515098639f94a8294a8e44e1358c52a
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
os.popen() is deprecated since version 2.6. Resolved with use of
subprocess module.
Change-Id: I4d0044c110c32f87ac0316a7e665e2bb9ea88813
Partial-Bug: #1529836
Currently, once they are in ‘error’ or ‘failed-over’ states you can’t
do anything with them. We need to allow enable_replication after the
admin has resolved any issues that may have prevented the operation.
Same thing for after a fail-over, you cannot enable replication on it.
This change allows for more states to be recoverable via enable
replication. It also more uniformly sets the state to ‘error’ when
something bad happens.
'enabled' --> replication is on.
'disabled' --> replication is off by design.
'failed-over' --> we have just failed over. Replication is off.
'error' --> an error occurred during the last operation.
allowed flow is:
'enabled' --> 'failed-over'/'disabled'/'error'
'error' --> 'enabled'/'error'
'disabled' --> 'enabled'/'error'
'failed-over' --> 'enabled'/'error'
Change-Id: Icbc22b8501b048b1755019305430177ba0a9385f
Partial-Bug: #1491631
This adds a description of the generation of opts.py and
cinder.conf.sample, the commands to generate them, and the scripts
that do the work generating them.
Change-Id: I6217e81acb9ee49c66cd510d55b40e1fd6fc3b3b
We were planning to let the list targets call be a
free for all, and just be a generic dict of info.
This probably isn't such a great idea, inparticular since
we have a required identifier field for each replication
device it makes more sense to just use that in the response
and leave the rest of the info internal.
In the future if there's a need we can always implement a
show command that displays all the dirty details.
This patch changes the identifier name to 'target_device_id'
to be more self describing, and updates the docstrings and
devref docs to reflect the changes and agreed upon changes.
Change-Id: If14130f5d5bb2e6df4478bd0e14a1f33d706bf78
Starting from this cycle (and stable Liberty) we're using reno for
release notes. This commit adds guidelines on when a release note is
required to be added.
Change-Id: If5aa6ab8317ec2f4295d899a45f80f11504d2a2c
Guru Meditation Reports (GMR) code in oslo.reports was recently updated
to expect SIGUSR2 as opposed to SIGUSR1, because it is reserved by
Apache 'mod_wsgi' for its own use.
Signal was changed and merged in change:
I9d3b6079ba2cca41fe4723723a6f80b2c3c0b9c0
Change-Id: Id58dd3c32b095f4c6b14caf650d36f2fc7dfb12c
Fix the example command for running a unit test.
(Colon versus period.)
Fix box formatting for tox commands. (Need extra
newline after double colon.)
Fix a typo in the same section.
Fix broken ostestr doc link.
Remove testr and flake8 links that don't go anywhere.
Change-Id: I243e4f0639ef4a87e8950e0428b7556919094b0e
This patch proposes a thorough update to the development doc
for the volume migration. Several improvements to volume
migration have been made during the last development cycle
and this patch attempts to document the current state.
Change-Id: Ibe233d82a0694b29ecdf4abce4af735b34821c3f
Partial-implements: blueprint migration-improvement
The first pass at setting up config entries for
replication targets was a hacky custom string parser
with its own unique syntax.
A better option is to use oslo.cfg's MultiOpt in conjunction
with Dict types so we can eliminate quite a bit of custom
parsing and most importantly use a standard syntax for conf
entries to make things easy for admins and reduce the
probability of syntax errors and mistakes in config setttings.
Change-Id: Ie300c1f1db548d258906eebbcea8265583086468
Closes-Bug: #1504696
One thing that may be needed by some back ends
that are implementing replication is some sort
of back end device identifier.
For managed back ends this shouldn't be an issue
but for unmanaged, it's handy to have some sort
of identifier string.
This patch just adds that to the response examples
in the volume.manager code as well as adds an update
to the dev docs to point it out.
Change-Id: Ic113d905e65c756439425b03035179e65ce0b39e
As per:
http://lists.openstack.org/pipermail/openstack-dev/2015-August/073338.html
The point behind the addition of the stevedore.sphinxext extension is
"to document drivers and other types of plugins to make the available
sets built into projects easier to discover" (dhellman).
Change-Id: I8427398e8d01c36f346e493a8144c1012ca7c5bf
Add new documentation with steps how to deploy Cinder API under Apache.
Implements: blueprint non-eventlet-wsgi-app
Change-Id: I25335991206a2563d266baac6730d130890777db
This adds a scaled back replication implementation
that leaves the bulk of the work up to the driver.
We just provide basic admin API methods to do things
like enable/disable and fail-over. Set up and
specification of replication targets for a specific
back end are now intended to be part of the cinder.conf
in the driver section itself.
Replication targets are configured via the cinder.conf
file in their associated driver section. See the devref
doc included in this commit for details on the format.
The next step in configuration is to create a volume-type
with replication info in the extra-specs.
extra-specs = replication=enable, volume_backend_name=foo
This instructs the driver to utilize replication, default is
up to the driver but would suggest single way rep and in the case
of multiple targets, driver could choose or have a default.
If the back end doesn't report replication=enabled in it's stats
updates the scheduler will fail to place the volume due to invalid
host, or no hosts available.
Vendors can easily modify extra-specs or their own config settings
to modify this behavior, any vendor-unique adaptation can be
provided through the use of scoped keys. Suggested examples
will be published in docs.
See doc/source/devref/replication.rst for more info
Implements BP: replication-v2
DocImpact
Change-Id: I406390e4d5f3c9947df1c4f2de68821e0fd7f75b
Simple update for our painfully out of date devref docs.
Just a short refresh on unit_tests, there's a lot that could
and probably should be added there, but this change just gets
rid of the obsolete references to Nose and adds info regarding
tox and how to use it.
Change-Id: Ib1ff174ee9ccb8ecb258558d77202062204dfec3
Remove URLs from jenkins.rst which is no longer exist
and fix incorrect URLs.
Change-Id: I7418dbe35518987de96fa31bcedb85a5d92cdc2e
Closes-Bug: #1480012
Cinder doesn't support EC2 API and doesn't contain cinder.api.ec2
module.
Also references to cinder.api.openstack.auth and cinder.api.cloud were
removed too.
Change-Id: I30f71cf541d93d3ab68780328e2dea6ebd326b63
The Guru Meditation Reports has graduated from oslo-incubator, Cinder
should switch to use oslo.reports to keep the code base clean.
NOTE: this should be merged after the requirements has been synchronized.
Change-Id: Ic91a0c5eed09ecdec93e707e901f4bcc55980f72
Closes-Bug: 1469575
Add "from six.moves import range" to replace the builtin range()
function with six.moves.range() to always create an iterator, instead of
creating a temporary list.
Replace "xrange" with "range".
Don't add the import for ranges of 1024 items or less.
Blueprint cinder-python3
Change-Id: If618b4e810e444f7eb6592bb2398805e9d14d548
This commit integrates functionality from the
`openstack.common.report` module into Cinder.
This enables Cinder services to receive SIGUSR1
and print a Guru Meditation Report to stderr.
The required modules were added to
'openstack-common.conf' as well.
It is essentially a copy from implementation of
nova side.
Change-Id: I5bbdc0f97db9b0ebd7b48e50ab7869e2ca33aead
Implements: blueprint guru-meditation-report
When generating docs, the modules listed under api all seem to be
missing the first letter after "cinder." at the beginning.
Change-Id: I924e55642350d3bb813ebab7cb978915fdd8b964
Closes-bug: #1408828
Replace URLs for workflow documentation to appropriate parts of the
OpenStack Project Infrastructure Manual.
Change-Id: I1e0c546a72c75193e8c742c02dc189d178a0312c
When running 'find cinder/' on OSX platforms, all returned paths
will have 2 slashes (//). Because the script only strips
the first slash as per the CINDER_DIR value, we end up
with module names such as "cinder..db.api" in the documentation.
This change trims the leading dot if found to avoid this situation.
Change-Id: I9423b253d9842295850f469757e928bf5856967a
The packages listed for Linux distros are updated to meet the
prerequisites to run the unit tests.
Change-Id: Iedd9e4d04d7700d418ddb07881ac76ad758466cb
Closes-bug: #1367670
