Open Stack

Agreed on the requirements of test results to qualify the vendor plugin to
be listed in the upstream docs.
Is there any procedure/infrastructure currently available for this
purpose?..
Pls. fwd any link/pointers on those info.

Thanks,
Vad
--

On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki <amotoki at gmail.com> wrote:

> I agree with Kevin and Kyle. Even if we decided to use separate tree for
> neutron
> plugins and drivers, they still will be regarded as part of the upstream.
> These plugins/drivers need to prove they are well integrated with Neutron
> master
> in some way and gating integration proves it is well tested and integrated.
> I believe it is a reasonable assumption and requirement that a vendor
> plugin/driver
> is listed in the upstream docs. This is a same kind of question as
> what vendor plugins
> are tested and worth documented in the upstream docs.
> I hope you work with the neutron team and run the third party requirements.
>
> Thanks,
> Akihiro
>
> On Tue, Oct 14, 2014 at 10:09 AM, Kyle Mestery <mestery at mestery.com>
> wrote:
> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton <blak111 at gmail.com> wrote:
> >>>The OpenStack dev and docs team dont have to worry about
> >>> gating/publishing/maintaining the vendor specific plugins/drivers.
> >>
> >> I disagree about the gating part. If a vendor wants to have a link that
> >> shows they are compatible with openstack, they should be reporting test
> >> results on all patches. A link to a vendor driver in the docs should
> signify
> >> some form of testing that the community is comfortable with.
> >>
> > I agree with Kevin here. If you want to play upstream, in whatever
> > form that takes by the end of Kilo, you have to work with the existing
> > third-party requirements and team to take advantage of being a part of
> > things like upstream docs.
> >
> > Thanks,
> > Kyle
> >
> >> On Mon, Oct 13, 2014 at 11:33 AM, Vadivel Poonathan
> >> <vadivel.openstack at gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> If the plan is to move ALL existing vendor specific plugins/drivers
> >>> out-of-tree, then having a place-holder within the OpenStack domain
> would
> >>> suffice, where the vendors can list their plugins/drivers along with
> their
> >>> documentation as how to install and use etc.
> >>>
> >>> The main Openstack Neutron documentation page can explain the plugin
> >>> framework (ml2 type drivers, mechanism drivers, serviec plugin and so
> on)
> >>> and its purpose/usage etc, then provide a link to refer the currently
> >>> supported vendor specific plugins/drivers for more details.  That way
> the
> >>> documentation will be accurate to what is "in-tree" and limit the
> >>> documentation of external plugins/drivers to have just a reference
> link. So
> >>> its now vendor's responsibility to keep their  driver's up-to-date and
> their
> >>> documentation accurate. The OpenStack dev and docs team dont have to
> worry
> >>> about gating/publishing/maintaining the vendor specific
> plugins/drivers.
> >>>
> >>> The built-in drivers such as LinuxBridge or OpenVSwitch etc can
> continue
> >>> to be "in-tree" and their documentation will be part of main Neutron's
> docs.
> >>> So the Neutron is guaranteed to work with built-in plugins/drivers as
> per
> >>> the documentation and the user is informed to refer the "external
> vendor
> >>> plug-in page" for additional/specific plugins/drivers.
> >>>
> >>>
> >>> Thanks,
> >>> Vad
> >>> --
> >>>
> >>>
> >>> On Fri, Oct 10, 2014 at 8:10 PM, Anne Gentle <anne at openstack.org>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <blak111 at gmail.com>
> wrote:
> >>>>>
> >>>>> I think you will probably have to wait until after the summit so we
> can
> >>>>> see the direction that will be taken with the rest of the in-tree
> >>>>> drivers/plugins. It seems like we are moving towards removing all of
> them so
> >>>>> we would definitely need a solution to documenting out-of-tree
> drivers as
> >>>>> you suggested.
> >>>>>
> >>>>> However, I think the minimum requirements for having a driver being
> >>>>> documented should be third-party testing of Neutron patches.
> Otherwise the
> >>>>> docs will become littered with a bunch of links to drivers/plugins
> with no
> >>>>> indication of what actually works, which ultimately makes Neutron
> look bad.
> >>>>
> >>>>
> >>>> This is my line of thinking as well, expanded to "ultimately makes
> >>>> OpenStack docs look bad" -- a perception I want to avoid.
> >>>>
> >>>> Keep the viewpoints coming. We have a crucial balancing act ahead:
> users
> >>>> need to trust docs and trust the drivers. Ultimately the
> responsibility for
> >>>> the docs is in the hands of the driver contributors so it seems those
> should
> >>>> be on a domain name where drivers control publishing and OpenStack
> docs are
> >>>> not a gatekeeper, quality checker, reviewer, or publisher.
> >>>>
> >>>> We have documented the status of hypervisor drivers on an OpenStack
> wiki
> >>>> page. [1] To me, that type of list could be maintained on the wiki
> page
> >>>> better than in the docs themselves. Thoughts? Feelings? More
> discussion,
> >>>> please. And thank you for the responses so far.
> >>>> Anne
> >>>>
> >>>> [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix
> >>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan
> >>>>> <vadivel.openstack at gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Anne,
> >>>>>>
> >>>>>> Thanks for your immediate response!...
> >>>>>>
> >>>>>> Just to clarify... I have developed and maintaining a Neutron
> plug-in
> >>>>>> (ML2 mechanism_driver) since Grizzly and now it is up-to-date with
> Icehouse.
> >>>>>> But it was never listed nor part of the main Openstack releases.
> Now i would
> >>>>>> like to have my plugin mentioned as "supported
> plugin/mechanism_driver for
> >>>>>> so and so vendor equipments" in the docs.openstack.org, but
> without having
> >>>>>> the actual plugin code to be posted in the main Openstack GIT
> repository.
> >>>>>>
> >>>>>> Reason is that I dont have plan/bandwidth to go thru the entire
> process
> >>>>>> of new plugin blue-print/development/review/testing etc as required
> by the
> >>>>>> Openstack development community. Bcos this is already developed,
> tested and
> >>>>>> released to some customers directly. Now I just want to get it to
> the
> >>>>>> official Openstack documentation, so that more people can get this
> and use.
> >>>>>>
> >>>>>> The plugin package is made available to public from Ubuntu
> repository
> >>>>>> along with necessary documentation. So people can directly get it
> from
> >>>>>> Ubuntu repository and use it. All i need is to get listed in the
> >>>>>> docs.openstack.org so that people knows that it exists and can be
> used with
> >>>>>> any Openstack.
> >>>>>>
> >>>>>> Pls. confrim whether this is something possible?...
> >>>>>>
> >>>>>> Thanks again!..
> >>>>>>
> >>>>>> Vad
> >>>>>> --
> >>>>>>
> >>>>>> On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle <anne at openstack.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan
> >>>>>>> <vadivel.openstack at gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> How to include a new vendor plug-in (aka mechanism_driver in ML2
> >>>>>>>> framework) into the Openstack documentation?.. In other words, is
> it
> >>>>>>>> possible to include a new plug-in in the Openstack documentation
> page
> >>>>>>>> without having the actual plug-in code as part of the Openstack
> neutron
> >>>>>>>> repository?... The actual plug-in is posted and available for the
> public to
> >>>>>>>> download as Ubuntu package. But i need to mention somewhere in
> the Openstack
> >>>>>>>> documentation that this new plugin is available for the public to
> use along
> >>>>>>>> with its documentation.
> >>>>>>>
> >>>>>>>
> >>>>>>> We definitely want you to include pointers to vendor documentation
> in
> >>>>>>> the OpenStack docs, but I'd prefer make sure they're gate tested
> before they
> >>>>>>> get listed on docs.openstack.org. Drivers change enough
> release-to-release
> >>>>>>> that it's difficult to keep up maintenance.
> >>>>>>>
> >>>>>>> Lately I've been talking to driver contributors (hypervisor,
> storage,
> >>>>>>> networking) about the out-of-tree changes possible. I'd like to
> encourage
> >>>>>>> even out-of-tree drivers to get listed, but to store their main
> documents
> >>>>>>> outside of docs.openstack.org, if they are gate-tested.
> >>>>>>>
> >>>>>>> Anyone have other ideas here?
> >>>>>>>
> >>>>>>> Looping in the OpenStack-docs mailing list also.
> >>>>>>> Anne
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Pls. provide some insights into whether it is possible?.. and any
> >>>>>>>> further info on this?..
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Vad
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> OpenStack-dev mailing list
> >>>>>>>> OpenStack-dev at lists.openstack.org
> >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> OpenStack-dev mailing list
> >>>>>>> OpenStack-dev at lists.openstack.org
> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OpenStack-dev mailing list
> >>>>>> OpenStack-dev at lists.openstack.org
> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Kevin Benton
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Kevin Benton
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Akihiro Motoki <amotoki at gmail.com>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141014/9ce963cf/attachment.html>