[openstack-dev] [all] Improving Vendor Driver Discoverability

Morales, Victor victor.morales at intel.com
Wed Jan 18 17:38:16 UTC 2017


Just a FYI, Ankur have been working on have a Feature Classification Matrix in Neutron[1] which collects some of this information

[1] https://review.openstack.org/#/c/318192/

Regards/Saludos
Victor Morales
Irc: electrocucaracha





On 1/13/17, 10:29 PM, "Mike Perez" <thingee at gmail.com> wrote:

>Hello all,
>
>In the spirit of recent Technical Committee discussions I would like to bring
>focus on how we're doing vendor driver discoverability. Today we're doing this
>with the OpenStack Foundation marketplace [1] which is powered by the driverlog
>project. In a nutshell, it is a big JSON file [2] that has information on which
>vendor solutions are supported by which projects in which releases. This
>information is then parsed to generate the marketplace so that users can
>discover them. As discussed in previous TC meetings [3] we need to recognize
>vendors that are trying to make great products work in OpenStack so that they
>can be successful, which allows our community to be successful and healthy.
>
>In the feedback I have received from various people in the community, some
>didn’t know how it worked, and were unhappy that the projects themselves
>weren’t owning this. I totally agree that project teams should own this and
>should be encouraged to be involved in the reviews. Today that’s not happening.
>I’d like to propose we come up with a way for the marketplace to be more
>community-driven by the projects that are validating these solutions.
>
>At the Barcelona Summit [4] we discussed ways to improve driverlog. Projects
>like Nova have a support matrix of hypervisors in their in-tree documentation.
>Various members of the Cinder project also expressed interest in using this
>solution. It was suggested in the session that the marketplace should just link
>to the projects' appropriate documentation. The problem with this solution is
>the information is not presented in a consistent way across projects, as
>driverlog does it today. We could accomplish this instead by using a parsable
>format that is stored in each appropriate project's git repository. I'm
>thinking of pretty much how driverlog works today, but broken up into
>individual projects.
>
>The marketplace can parse this information and present it in one place
>consistently. Projects may also continue to parse this information in their own
>documentation, and we can even write a common tool to do this. The way a vendor
>is listed here is based on being validated by the project team itself. Keeping
>things in the marketplace would also address the suggestions that came out of
>the recent feedback we received from various driver maintainers [4].
>
>The way validation works is completely up to the project team. In my research
>as shown in the Summit etherpad [5] there's a clear trend in projects doing
>continuous integration for validation. If we wanted to we could also have the
>marketplace give the current CI results, which was also requested in the
>feedback from driver maintainers.
>
>I would like to volunteer in creating the initial files for each project with
>what the marketplace says today.
>
>[1] - https://www.openstack.org/marketplace/drivers/
>[2] - http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
>[3] - http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-10-20.01.log.html#l-106
>[4] - http://lists.openstack.org/pipermail/openstack-dev/2017-January/109855.html
>[5] - https://etherpad.openstack.org/p/driverlog-validation
>
>-- 
>Mike Perez
>
>__________________________________________________________________________
>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


More information about the OpenStack-dev mailing list