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.dang...@ibm.com
On Tue, Jan 10, 2017 at 12:33 AM, Steve Martinelli <s.martine...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ 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