Hi,
*>>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <[email protected] <[email protected]>> 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.* [Vad] while i 'm waiting for the conclusion on this subject, i 'm trying to setup the third-party CI/Test system and meet its requirements to get my mechanism_driver listed in the Kilo's documentation, in parallel. Couple of questions/confirmations before i proceed further on this direction... 1) Is there anything more required other than the third-party CI/Test requirements ??.. like should I still need to go-through the entire development process of submit/review/approval of the blue-print and code of my ML2 driver which was already developed and in-use?... 2) Who is the authority to clarify and confirm the above (and how do i contact them)?... Thanks again for your inputs... Regards, Vad -- On Tue, Oct 14, 2014 at 3:17 PM, Anne Gentle <[email protected]> wrote: > > > On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan < > [email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> wrote: >>> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton <[email protected]> >>> 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 >>> >> <[email protected]> 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 <[email protected]> >>> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <[email protected]> >>> 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 >>> >>>>> <[email protected]> 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 <[email protected] >>> > >>> >>>>>> wrote: >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan >>> >>>>>>> <[email protected]> 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 >>> >>>>>>>> [email protected] >>> >>>>>>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> _______________________________________________ >>> >>>>>>> OpenStack-dev mailing list >>> >>>>>>> [email protected] >>> >>>>>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> OpenStack-dev mailing list >>> >>>>>> [email protected] >>> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Kevin Benton >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> OpenStack-dev mailing list >>> >>>>> [email protected] >>> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> OpenStack-dev mailing list >>> >>>> [email protected] >>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> OpenStack-dev mailing list >>> >>> [email protected] >>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Kevin Benton >>> >> >>> >> _______________________________________________ >>> >> OpenStack-dev mailing list >>> >> [email protected] >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > [email protected] >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> -- >>> Akihiro Motoki <[email protected]> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
