Re: [openstack-dev] [DriverLog] DriverLog future
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
Re: [openstack-dev] [DriverLog] DriverLog future
> -Original Message- > From: Matt Riedemann [mailto:mriede...@gmail.com] > Sent: Thursday, March 01, 2018 4:19 AM > To: openstack-dev@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- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
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. 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [DriverLog] DriverLog future
Having 3rd party CI report results automatically will be helpful. While it is possible for PTLs to report per release which drivers should be listed in marketplace for release, currently PTLs are signed for this extra work. Driver owners submitting DriverLog updates per release – not a big deal. Extra work on Ilya. I think we can define a rule for removal. If driver entry was not updated for 2(?) releases then remove it. We can run questionnaire for what the right # for it. Thanks, Arkady From: Ilya Shakhat [mailto:shak...@gmail.com] Sent: Thursday, March 1, 2018 4:44 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [DriverLog] DriverLog future 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? Thanks, I [1] http://stackalytics.com/report/driverlog [2] https://www.openstack.org/marketplace/drivers/ [3] http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html __ 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
[openstack-dev] [DriverLog] DriverLog future
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? Thanks, I [1] http://stackalytics.com/report/driverlog [2] https://www.openstack.org/marketplace/drivers/ [3] http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html __ 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
