[openstack-dev] [Neutron] PTL Candidacy

Armando M. armamig at gmail.com
Tue Jan 24 21:01:02 UTC 2017


On 24 January 2017 at 12:46, 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?
>

Even though I am not the one running, I am replying here because I feel
compelled as outgoing PTL and member of the core team to help the soon PTL
elect through this process.

In my opinion, the first thing to address is to lay down the foundations
for an objective comparison across drivers. The neutron team is obviously
best position in doing that. This was started with how we chose to organize
the neutron project, what quality criteria mattered for the team, and how
qualifying neutron features can be tracked across releases (e.g. still work
in progress in [1]).

Only after we have these solid foundations in place, we can go about the
effort of tracking the wider ecosystem of neutron plugins, and identify who
is best positioned to keep that snapshot accurate over time.

My 2c
Armando

[1] https://review.openstack.org/#/c/318192/


> --
> Jeremy Stanley
>
> __________________________________________________________________________
> 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/f868df5b/attachment.html>


More information about the OpenStack-dev mailing list