This is the start of an effort to both validate that drivers fully
implement the expected minimum requirements as well as to create a clear
place for driver developers to learn what needs to be implemented and get
documentation explaining what is expected for each method.
This also enables us to create tooling for documenting the available
drivers and their capabilities, to some degree. A follow up patch will
show some of what I'm thinking there, but it will make it possible to write
scripts for different needs.
This is somewhat a cleanup attempt to the ABC work that was started a
while back. This does not aim to replace that effort, but give a
mechanism for some of the things expected out of that effort that ended
up not being possible with how it evolved.
In most cases we do not really care if a driver is inherited from a
certain base class, just that it conforms to the given interface.
The interface/inheritance work really centers around two separate
things:
* Ensuring drivers conform to an expected interface
* Allowing code reuse and common implementation
This is really for the first item. Additional work is needed to complete
the ABC work we've done, but that really focuses on the second item, and
is out of scope for the intent of this patch.
Change-Id: I4168225126fe88c31712d94f0a130e9e7ede3446
We now have unit, functional, and tempest tests in tree. To avoid
confusion, we need to make sure it's clear what each of these test
types are intended to be used for.
This adds a description for each test type and cleans up some of
the documentation around testing in general.
Change-Id: I15bba187889e058adbf03deb4308a41d0a6248e3
There was no mention in conditional updates devref on what kind of error
messages are we expected to return with conditional updates and why we
decided to go with generic errors instead of specific errors like we had
before.
Change-Id: I079a815a656ce5a5c0e05e2e20f26df6ea700547
This patch fixes the formatting of the man page and removes the
unnecessary maintenance of a date and version.
Change-Id: Idf78bbed44f942bb6976ccf4da67c748d9283ed9
When running a delete CG operation on a MySQL DB engine we'll get an
error from the DB: "You can't specify target table 'consistencygroups'
for update in FROM clause".
This is caused by a non standard behavior only in MySQL, as SQLite and
PostgreSQL work as expected, on filter `cg_creating_from_src` that
checks that we are not using the CG we are trying to delete to create
another CG at this very moment, CGs that were previously created from
this CG are not considered.
This patch changes the way we perform the filter using a select subquery
as a workaround for MySQL unexpected behavior and updates devref to warn
about this unexpected MySQL behavior.
Change-Id: Ic10de411ffeceb00f1e8525906995bd8b2f49777
Closes-Bug: #1588487
The oslo sphinxconfiggen module was added to the oslo.config
2.3.0 release. This enables config file generation as part of
the sphinx doc generation.
The generated config file will pick up the current config
options from the code base. And as an added bonus, it will
now be published to the docs.openstack.org site for easy
reference or download.
This also puts us inline with what other projects like Nova
are doing for sample config files and is the recommended
method from the Oslo team.
Change-Id: I912a97eb2686d3dc56e50d8641d7bd930179bc18
Include information regarding both minimum and maximum versions
of the API microversion.
Change-Id: Ie3acdcbf323af40bdb4f3ff20fcf2d3e8eb9606d
Closes-Bug: #1582460
This patch adds developer's documentation for conditional update
functionality used to remove API races.
Change-Id: I63ce1c87f7418feba94479b461a4488d4ae6e48c
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
Noticed a few trivial typos while looking through the migration
devref that could be fixed up. Some larger rewording might help
clarify some things, but this just fixes some specific instances.
Change-Id: I24c59f8b1725c8c5c93101983e7a3c4dc2a91065
This devref page was still sending folks to the long-unused
Launchpad Answer site. Patch updates to inform the reader
that Ask OpenStack may be a better bet these days.
Change-Id: I8b2e2379c1300822d9cddab225835de6d2d8fa80
When building packages if git is absent, then we should not set
html_last_updated_fmt. It can still be set via the -D switch
when building with sphinx-build.
Change-Id: Ib289335198b0fe0a00922cbfe5c7fd7ff438ffcf
Closes-Bug: #1552251
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
