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

Flavio Percoco flavio at redhat.com
Tue Jan 10 07:54:11 UTC 2017


On 10/01/17 02:33 -0500, Steve Martinelli wrote:
>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.

Thanks for sending this out, Steve.

I've posted a link to this summary on the currently open reviews on this topic
and I'll comment further there.

Cheers,
Flavio

>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,
>etc).
>
>* 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.
>
>Discoverability
>
>===============
>
>* 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
>project.
>
>* 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
>teams).
>
>* 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
>https://github.com/openstack/ironic/tree/master/ironic/drivers
>
>* Neutron has all drivers out-of-tree, with project names like:
>‘networking-cisco’.
>
>* 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
>out-of-tree.
>
>thanks for reading! stevemar

>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/cea513cd/attachment.pgp>


More information about the OpenStack-dev mailing list