There's been an intermittent issue where getting a list of all
drivers would fail to get all defined classes. With recent local
tests, once it got 103 drivers, but several times it got 69
drivers.
This appears to be from exceptions thrown while loading the
decorated classes with various cinder.objects classes not being
defined. To get around this, this adds an explicit load of all
cinder.objects before attempting to get the driver classes.
Change-Id: Ief4a93ec2d8256424166c7bf3b9d48a79a6e5e54
For lack of a better way, for drivers that have CI run by Jenkins we
denote this using the name 'Cinder_Jenkins'. CI links were added to
the generated driver list, but for these drivers this results in a
link to an invalid wiki page. For these drivers we should just skip
adding the CI info link.
Change-Id: I8a3087f8102392ca604a42fdf006e1a4e1a026d6
Appending "unsupported" to the driver name in the driver listing
for unsupported drivers. The instance variable "_supported" in
BaseVD is changed to class variable "SUPPORTED" so that the supported
status of drivers can be read after loading the driver modules.
Change-Id: I21ca9137a847873f2ec026520daf8b97603d1888
The 'dict' output format prints the CI wiki name, but it is
missing in the 'str' output format. Adding CI wiki page to
the 'str' output format.
Change-Id: Ib62864221702d18a4f49118180b9af65f069ec4a
This patch adds a CI_WIKI_NAME to each driver object. The value is the exact
name of the ThirdPartySystems wiki page. This allows us to create an
automated tool to associated jobs to drivers and track their CI reporting
status correctly.
This patch also updates the generate_driver_list.py script to output the
driver list as a python list of dicts that can be directly consumed.
Change-Id: I0ec5f705e91f680a731648cf50738ea219565f70
When you run the generate_driver_list.py file from inside the
tools dir, it pukes out an AttributeError for NoneType object
has no attribute 'close'. This patch makes sure that exiting
doesn't cause a puke.
Change-Id: Ib6c4f451096cd07d0423941cab52ffa8cd8dc471
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
tools/generate_driver_list.py assumes that the current directory is
the Cinder root directory. If the script is run from a different
directory, it doesn't generate the driver info. This patch changes
the current directory to the root directory before calling the
utility functions to generate the driver list.
Closes-bug: #1604269
Change-Id: I35829003868531ccd76ee26e83e0b51067984a6a
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
It is useful to have a maintained (in source control) list
of drivers that exist in Cinder. It could be used in docs
and unit tests to check method impl on backend drivers.
This change add tool for generate list of drivers based on
existing BaseVD class in class hierarchy of volume drivers.
Output example:
Drivers: ['cinder.volume.drivers.lvm.LVMVolumeDriver',
'cinder.volume.drivers.rbd.RBDDriver',
...]
Implements: blueprint drivers-list-generator
Change-Id: I0e10906873e659e09a6e34531a0c932495d7c399
