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" <thin...@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-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
