On 01/03/2017 23:53, Mike Perez wrote: > Hey all, > > I kicked off a thread [1] to start talking about approaches with improving > vendor discoveribility by improving our Market Place [2]. In order to improve > our market place, having the projects be more part of the process would allow > the information to be more accurate of what vendors have good support in the > respected service. > > It was discovered that we have a common solution of using INI files and > parsing > that with a common support-matrix.py script that originated out of nova [3]. > I would like to propose we push this into some common sphinx extension > project. > Are there any suggestions of where that could live? > > I've look at how Nova [3][4], Neutron [5][6] and Designate [7][8] are doing > this today. Nova and Neutron are pretty close, and Designate is a much more > simplified version. Cinder [9][10] is not using INI files, but instead going > off the driver classes themselves. Are there any other projects I'm missing? > > Cinder and Designate have drivers per row, as oppose to Nova and Neutron > which have features per row. This makes sense given the difference in drivers > versus features? > > I'm assuming the Designate matrix is saying every driver supports every > feature > in its API? If so, that's so awesome and makes me happy.
yes :) - our drivers are *very* thin and just do zone create / update / delete, and the rest of the complexity is in Designate. > I would like to start brainstorming on how we can converge on a common matrix > table design so things are a bit more consistent and easier for a common > parsing tool. > I think having an os-api-ref for drivers (os-driver-ref ??) is a great idea. What I would like to see from that is a common data format for listing drivers, which we could then use for a overall driver "market place". What we (designate) store per driver: Name Type (Agent vs Zone Transfer) Status (Which is a dynamic list in the ini file) Maintainers Variations (e.g. PowerDNS with MySQL vs pgSQL) Repo I want to extend ours to include: Links to setup / usage docs for that driver. Links to example pool config snippets. I understand that ^ may be quite difficult to get right in a generic way, so if we cannot make it work, we can keep ours separate. Thanks, Graham > > [1] - > http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html > [2] - https://www.openstack.org/marketplace/drivers/ > [3] - > https://docs.openstack.org/developer/nova/support-matrix.html#operation_maintenance_mode > [4] - > http://git.openstack.org/cgit/openstack/nova/tree/doc/ext/support_matrix.py > [5] - https://review.openstack.org/#/c/318192/76 > [6] - > http://docs-draft.openstack.org/92/318192/76/check/gate-neutron-docs-ubuntu-xenial/48cdeb7//doc/build/html/feature_classification/general_feature_support_matrix.html > [7] - > https://git.openstack.org/cgit/openstack/designate/tree/doc/ext/support_matrix.py > [8] - https://docs.openstack.org/developer/designate/support-matrix.html > [9] - https://review.openstack.org/#/c/371169/15 > [10] - > http://docs-draft.openstack.org/69/371169/15/check/gate-cinder-docs-ubuntu-xenial/aa1bdb1//doc/build/html/driver_support_matrix.html > __________________________________________________________________________ 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