[openstack-dev] [tc][all] Feedback from driver maintainers about future of driver projects

Steve Martinelli s.martinelli at gmail.com
Tue Jan 10 07:33:27 UTC 2017

In preparation for the next TC meeting, a survey was sent out to driver
maintainers, here is a summary of the feedback that was gathered.

Major observations


* Are drivers an important part of OpenStack? YES!

* Discoverability of drivers needs to be fixed immediately.

* It is important to have visibility in a central place of the status of
each driver.

* Perspective of a driver developer and a high level person at the company
should feel like they're part of something.

* OpenStack should stop treating drivers like second-class citizens. They
want access to the same resources (publish on docs.o.org, config guides,

* The initial wording about what constitutes a project was never intended
for drivers. Drivers are a part of the project. Driver developers
contribute to OpenStack by creating drivers.



* Consensus: It is currently all over the place. A common mechanism to view
all supported drivers is needed.

* Cinder list: http://docs.openstack.org/developer/cinder/drivers.html

* Nova list: http://docs.openstack.org/developer/nova/support-matrix.html

* Stackalytics list: http://stackalytics.openstack.org/report/driverlog

* Opinion: If we intend to use the marketplace (or anywhere on openstack.org)
to list in-tree and out-of-tree drivers, they should have CI results
available as a requirement. A driver that fails CI is not just a vendor
problem, it’s an OpenStack problem, it reflects poorly on OpenStack and the

* Opinion: What constitutes a supported driver, why not list all drivers?

* Opinion: Fixing discoverability can be done independently of governance
changes. We have the option of tabling the governance discussion until we
get the discoverability properly fixed, and see then if we still need to do
anything more.

* Opinion: Between giving full access to vertical resources to driver
teams, and making the marketplace *the* place for learning about OpenStack
drivers, we would have solved at least the biggest portion of the problem
we're facing.

Driver projects - official or not?


* Fact: There is desire from some out-of-tree vendors to become ‘official’
OpenStack projects, and gain the benefits of that (access to horizontal

* Opinion: Let drivers projects become official, there should be no 3rd
party CI requirement, that can be a tag.

* Opinion: Do not allow drivers projects to become official, that doesn’t
mean they shouldn’t easily be discoverable.

* Opinion: We don't need to open the flood gates of allowing vendors to be
teams in the OpenStack governance to make the vendors developers happy.

* Fact: This implies being placed under the TC oversight. It is a
significant move that could have unintended side-effects, it is hard to
reverse (kicking out teams we accepted is worse than not including them in
the first place), and our community is divided on the way forward. So we
need to give that question our full attention and not rush the answer.

* Opinion: Consider https://github.com/openstack/driverlog an official
OpenStack project to be listed under governance with a PTL, weekly
meetings, and all that it required to allow the team to be effective in
their mission of keeping the marketplace a trustworthy resource for
learning about OpenStack driver ecosystem.

Driver developers


* Opinion: A driver developer that ONLY contributes to vendor specific
driver code should not have the same influence as other OpenStack
developers, voting for PTL, TC, and ATC status.

* Opinion: PTLs should leverage the extra-atcs option in the governance repo

In-tree vs Out-of-tree


* Cinder has in-tree drivers, but also has out-of-tree drivers when their
CI is not maintained or when minimum feature requirements are not met. They
are marked as ‘not supported’ and have a single release to get things
working before being moved out-of-tree.

* Ironic has a single out-of-tree repo:
https://github.com/openstack/ironic-staging-drivers -- But also in-tree

* Neutron has all drivers out-of-tree, with project names like:

* Many opinions on the “stick-based” approach the cinder team took.

* Opinion: The in-tree vs out-of-tree argument is developer focused.
Out-of-tree drivers have obvious benefits (develop quickly, maintain their
own team, no need for a core to review the patch). But a vendor that is
looking to make sure a driver is supported will not be searching git repos
(goes back to discoverability).

* Opinion: May be worth handling the projects that keep supported drivers
in-tree differently that we handle projects that have everything

thanks for reading! stevemar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/1be7b52a/attachment.html>

More information about the OpenStack-dev mailing list