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)
pgpFI9A8f3PoE.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev