Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170706/c04c3666/attachment.sig>