>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. 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
