We have tox -e gendriverlist that outputs an RST-ish report of all drivers
in the tree. This output can be used in the docs build to automatically
publish the list of drivers to make it easier to find officially supported
drivers.
This effectively removes the existing drivers.html that was generated prior
that did not actually contain any useful information.
Change-Id: I8de78723af76aabcc976733ac4b248db0b8ca16f
Link the docstring generated documentation for the driver interfaces into
the drivers devref page for easy access to driver method documentation.
Change-Id: Ie22599fef99ebfac12f3b9bb251ae5bdfff4bff6
We had an extension for pulling out todo information from our docs. This
doesn't appear to have ever really been used though. Only a couple todo items
were published to the Cinder documentation, and the two published appear to
be extremely old.
Since this isn't really used and could just cause confusion, removing this
from the index page and removing the sphinx extension used to generate it.
Change-Id: I8993633538a5ee1687c4721bce3c520e8fb4ccfd
The information in the README file in the doc directory was very out of
date and the Makefile referenced in it doesn't appear to work any more.
Our preferred doc build method is to stay consistent with using tox -e docs,
so removing the legacy build information and providing better details for
doc development.
Change-Id: Ifd01b9cfc39fe99697a1669ecb5db6302359b662
Our existing `api_version` decorator for microversions forces us to use
"# noqa" if we have multiple microversions of a method in the same
class, providing no way around this.
This patch adds a way to avoid using noqa directive. Previously we
would have:
@wsgi.Controller.api_version("3.3")
def my_api_method(self, req, id):
.... method_1 ...
@wsgi.Controller.api_version("3.4") # noqa
def my_api_method(self, req, id):
.... method_2 ...
With this patch the second method does not require noqa anymore:
@my_api_method.api_version("3.4")
def my_api_method(self, req, id):
.... method_2 ...
Devref is updated to reflect this new change and to mention that it is
the recommended way to do it.
Change-Id: I46283b52cc6a347d5deb0f57a123eba4e01a3eb2
Closes-Bug: #1599806
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
