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
