On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan < vadivel.openst...@gmail.com> wrote:
> 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. > > Here's a link to the third-party testing setup information. http://ci.openstack.org/third_party.html Feel free to keep asking questions as you dig deeper. Thanks, Anne > Thanks, > Vad > -- > > On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki <amot...@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 <mest...@mestery.com> >> wrote: >> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton <blak...@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.openst...@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 <a...@openstack.org> >> wrote: >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <blak...@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.openst...@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 <a...@openstack.org> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan >> >>>>>>> <vadivel.openst...@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@lists.openstack.org >> >>>>>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> OpenStack-dev mailing list >> >>>>>>> OpenStack-dev@lists.openstack.org >> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> OpenStack-dev mailing list >> >>>>>> OpenStack-dev@lists.openstack.org >> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Kevin Benton >> >>>>> >> >>>>> _______________________________________________ >> >>>>> OpenStack-dev mailing list >> >>>>> OpenStack-dev@lists.openstack.org >> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> OpenStack-dev mailing list >> >>>> OpenStack-dev@lists.openstack.org >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> OpenStack-dev mailing list >> >>> OpenStack-dev@lists.openstack.org >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> Kevin Benton >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> Akihiro Motoki <amot...@gmail.com> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev