Open Stack

Thanks for working on this stevemar.
In the future, could we find a way to send such a survey to a broader
audience? I'm not on a Cinder driver maintainer list, but I work closely
with our driver maintainers and the OpenStack community, so I might be able
to respond more reliably to surveys like this.
thanks,
scottda
scott.dangelo at ibm.com

On Tue, Jan 10, 2017 at 12:33 AM, Steve Martinelli <s.martinelli at gmail.com>
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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/a8b457e5/attachment-0001.html>