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
