Kyle, Gentle reminder... when you get a chance!.. Anne, In case, if i need to send it to different group or email-id to reach Kyle Mestery, pls. let me know. Thanks for your help.
Regards, Vad -- On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan < vadivel.openst...@gmail.com> wrote: > 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 <a...@openstack.org> wrote: > >> >> >> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan < >> vadivel.openst...@gmail.com> wrote: >> >>> Hi, >>> >>> >>> >>> >>> >>> >>> >>> *>>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <blak...@gmail.com >>> <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.* >>> >>> [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 <a...@openstack.org> wrote: >>> >>>> >>>> >>>> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan < >>>> vadivel.openst...@gmail.com> 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 <amot...@gmail.com> >>>>> 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 <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 >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> _______________________________________________ >> 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
