Open Stack

On 01/13/2017 10:29 PM, 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.
Having the CI results reported would be an interesting experiment. I 
wonder if having the results even more publicly reported would result in 
more stable CI's.  It is a dual edged sword however. Given the 
instability of many CI's it could make OpenStack look bad to customers 
who don't understand what they are looking at.  Just my thoughts on that 
idea.
>
> 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
>