On Tue, Jan 24, 2017 at 3:24 PM, Edgar Magana <edgar.mag...@workday.com> wrote:
> You just made me remember my time as police man for Neutron plugins! ☺ > Now we can have distributed police men :-) -Sukhdev > > > Edgar > > > > *From: *Sukhdev Kapur <sukhdevka...@gmail.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Tuesday, January 24, 2017 at 3:14 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [Neutron] PTL Candidacy > > > > I remember good old days when CI was introduced in Neutron (during > Icehouse time frame). There was excellent momentum behind it. We did not > know some of the enforcement details, which created lots of > confusion/havoc. > > > > Now that we have a better understanding of the past issues, and lots of > good ideas to address them, I think it is appropriate to reactivate the > process. > > As to Jeremy's options, I think option B makes the best sense - the driver > author/owner should bare the burden of declaring a driver/plugin compatible. > > > > cheers.. > > -Sukhdev > > > > > > On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley <fu...@yuggoth.org> > wrote: > > On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote: > > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton <ke...@benton.pub> wrote: > > > I'm on board with getting visibility into the drivers with > improvements to > > > driverlog, etc. What I'm uncertain of is providing much in the lines of > > > 'validation'. Core reviewers don't frequently have access to the > hardware or > > > software required to validate these drivers so we can't be sure if the > > > features really are working as expected. > > > > > > If validation is as flexible as you highlighted in the email, we can at > > > least get it to a point where all recent CI runs are linkable from > driverlog > > > and people can see recent tempest runs. I don't foresee the Neutron > team > > > getting to a point soon where we vouch for certain drivers though just > > > because it is so hard to keep up with their changes (even ignoring > changes > > > in the vendor hardware itself). > > > > Good point. We may guide plugins and drivers on how to set up CI; we > > may help Foundation to set up Marketplace in such a way that would > > allow to automatically consume test artifacts from driver owners; we > > may provide guidance to Foundation about which features are more > > important to reflect that in Marketplace; but I would hope we don't > > put the Neutron team on the hook to validate each driver, or even > > police CI owners to produce consumable results. (The stick in the > > latter case would be driver not showing up in Marketplace, or showing > > up with no feature support information.) > > I guess the question I have is who, then, can tell our > operators/users what Neutron drivers are reasonably supported? It > sounds like you're saying Neutron developers are not well-placed to > determine that, which leaves us with these other options: > > A. Have the OpenStack Foundation as maintainers of the Marketplace > decide which Neutron drivers are usable (they don't really staff > for this purpose so would be throwing darts I think) > > B. Trust the driver authors to declare whether they're supported and > what features they provide (maybe that works better than I > expect?) > > C. Identify another party with a vested interest in validating > driver support (a board of operators from different organizations > maybe?) > > D. Provide links/aggregation of QA/CI and let the consumers attempt > to divine supportability for themselves (seems a bit downstream > hostile) > > Are any of those options preferable? > -- > Jeremy Stanley > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=stAqZEa1UaR75JvzJ0FZBG0scAKmZwHhoC7exuAKsUc&s=J3l_htX2j4f1reTu2w6i8YUD4Q_0YgpguIiCHlJB0PE&e=> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=stAqZEa1UaR75JvzJ0FZBG0scAKmZwHhoC7exuAKsUc&s=j5yF8PsqCjQ64dZ3etZCnJfe9H7rlO9gO1xHDXbUf50&e=> > > > > __________________________________________________________________________ > 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
