[openstack-dev] [Neutron] PTL Candidacy

Sukhdev Kapur sukhdevkapur at gmail.com
Tue Jan 24 23:51:07 UTC 2017


On Tue, Jan 24, 2017 at 3:24 PM, Edgar Magana <edgar.magana at 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 <sukhdevkapur at gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Tuesday, January 24, 2017 at 3:14 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <fungi at 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 <kevin at 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-request at 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-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/20170124/41da61b5/attachment.html>


More information about the OpenStack-dev mailing list