On 20:29 Jan 13, Mike Perez 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
Hey all, Continuing things, posted for review is the initial project [1][2], add it to test-requirements [3] and changes for Nova [4] and Neutron [5]. Review love appreciated! [1] - https://review.openstack.org/472260 [2] - https://review.openstack.org/472488 [3] - https://review.openstack.org/481294 [4] - https://review.openstack.org/481304 [5] - https://review.openstack.org/481307 -- Mike Perez
signature.asc
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
