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
