Hi Kyle, Can you pls. comment on this discussion and confirm the requirements for getting out-of-tree mechanism_driver listed in the supported plugin/driver list of the Openstack Neutron docs.
Thanks, Vad -- On Mon, Oct 20, 2014 at 12:48 PM, Anne Gentle <[email protected]> wrote: > > > On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan < > [email protected]> wrote: > >> 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?... >> >> > The neutron PTL Kyle Mestery can answer if there are any additional > requirements. > > >> 2) Who is the authority to clarify and confirm the above (and how do i >> contact them)?... >> > > Elections just completed, and the newly elected PTL is Kyle Mestery, > http://lists.openstack.org/pipermail/openstack-dev/2014-March/031433.html > . > > >> >> 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 >> >> > > _______________________________________________ > 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
