[openstack-dev] [DriverLog] DriverLog future

Mike Perez thingee at gmail.com
Mon Mar 5 15:56:25 UTC 2018

On 11:44 Mar 01, Ilya Shakhat wrote:
> Hi!
> For those who do not know, DriverLog is a community registry of 3rd-party
> drivers for OpenStack hosted together with Stackalytics [1]. The project
> started 4 years ago and by now contains information about 220 drivers. The
> data from DriverLog is also consumed by official Marketplace [2].
> Here I would like to discuss directions for DriverLog and 3rd-party driver
> registry as general.
> 1) Being a single community-wide registry was good initially, it allowed to
> quickly collect description for most of drivers in a single place. But in a
> long term this approach stopped working - not many projects remember to
> update the information stored in some random place, right?
> Mike already pointed to this problem a year ago [3] and the idea was to
> move driver list to projects (and thus move responsibility to them too) and
> have an aggregated list of drivers produced by infra. Do we have any
> progress in this direction? Is it a time to start deprecation of DriverLog
> and consider transition during Rocky release?
> 2) As a project with 4 years history DriverLog's list only increased over
> the time with quite few removals. Now it still has drivers with the latest
> version Liberty or drivers for non-maintained projects (e.g. Fuel). While
> it maybe makes sense to keep all of them for operators who run older
> versions, it may produce a feeling that the majority of drivers are old.
> One of solutions for this is to show by default drivers for active releases
> only (Pike and ahead). If done this will apply to both DriverLog and
> Marketplace.
> Any other ideas or suggestions?

Hey Ilya,

Yes there is progress. Thanks to others who have helped me, we have a project
called sphinx-feature-classification [0]. This allows a project to use a sphinx
directive to generate a support matrix based on drivers recorded in a INI file
[1] which lives in the project's repository.

I have also went through and found projects using the duplicate code this
library replaces and proposed changes to those projects [2].

Next steps in the library to account for:

* Releases
* Maintainers
* CI success/failure parsing patterns (do we still need this?)

Am I missing anything else? I noticed we have information in driver log and the
wiki [3] and I kind of don't know now what third-party CI's are dependent on to
work with gerrit. I'll check it out today and report back here, unless someone
knows and replies before I get a chance.

[0] - http://git.openstack.org/cgit/openstack/sphinx-feature-classification
[1] - https://docs.openstack.org/sphinx-feature-classification/latest/usage.html
[2] - https://review.openstack.org/#/q/status:+open+topic:support-matrix
[3] - https://wiki.openstack.org/wiki/ThirdPartySystems

Mike Perez (thingee)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180305/9d1ca798/attachment.sig>

More information about the OpenStack-dev mailing list