Open Stack

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedemos at gmail.com]
> Sent: Thursday, March 01, 2018 4:19 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [DriverLog] DriverLog future
> 
> On 3/1/2018 10:44 AM, Ilya Shakhat wrote:
> >
> > 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.

If you want to default to showing only drivers for active releases, you have to provide a method for users to find which drivers are available for *any* specific release no matter how old (although Juno is likely the furthest back we would want to go).  There are lots of people who haven't upgraded to "living" releases, but still need to maintain their clouds, which might mean getting an as yet not acquired driver for their cloud release.  Remember, even Interop certification goes back three releases.

You can unclutter the pages a bit by defaulting to displaying current drivers, but you must still provide the historical lists.

--Rocky

> >
> > Any other ideas or suggestions?
> 
> As having recently went through that repo to update some of the nova driver
> maintainers, I noted the very old status of several of them.
> 
> I agree this information should live in the per-project repo documentation,
> not in a centralized location. Nova does a decent job about keeping the virt
> driver feature support matrix up to date, but definitely not when it's a
> separate repo. This is a similar problem to the centralized docs issue
> addressed as a community in Pike.
> 
> The OSIC team tried working on a feature classification effort [1] for a few
> releases which was similar to the driver log, specifically for showing which
> drivers and features had CI coverage. That work is *very* incomplete and no
> longer maintained, and I've actually been suggesting lately that we drop it
> since misinformation is almost worse than no information.
> 
> I suggested to Mike the other day that at the very least, the driver log docs
> should put a big red warning, like in [1], that the information may be old.
> 
> [1] https://docs.openstack.org/nova/latest/user/feature-classification.html
> 
> --
> 
> Thanks,
> 
> Matt
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev