<div dir="ltr">Hi Anne,<div><br></div><div>I provided my comment in the review itself.. and pasted below for your quick view. </div><div><br></div><div>Thanks,</div><div>Vad</div><div>--</div><div><br></div><div><table class="" style="width:1253px;border-spacing:0px;color:rgb(0,0,0);font-family:sans-serif;background-image:initial;background-repeat:initial"><tbody><tr class="" style="background:rgb(229,236,249)"><td class="" style="font-family:monospace;font-size:9pt;padding:0px;border-width:1px;border-style:solid;border-color:rgb(0,0,0) rgb(0,0,0) blue"><div class="" name="Vadivel Poonathan" style="font-family:sans-serif"><table class="" style="width:616px"><colgroup><col></colgroup><tbody><tr><td style="font-family:sans-serif;font-size:9pt;padding-top:0px;padding-bottom:0px"></td><td class="" title="Vadivel Poonathan <vadivel.openstack@gmail.com>" style="font-family:sans-serif;font-size:9pt;font-weight:bold;white-space:nowrap;padding-top:0px;padding-bottom:0px">Vadivel Poonathan</td><td class="" style="font-family:sans-serif;font-size:9pt;width:440px;padding-top:0px;padding-bottom:0px"></td><td class="" align="right" title="Dec 8, 2014 12:05 PM" style="font-family:sans-serif;font-size:9pt;white-space:nowrap;padding-top:0px;padding-bottom:0px">12:05 PM</td></tr></tbody></table><div class="" style="padding-bottom:1px"><div class="" style="font-size:small;padding-left:1px;padding-right:1px"><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em">I understand the "other drivers" mean the external drivers which are not part of the official openstack repository. So the reference drivers which are part of the official openstack repository will be "fully" documented and for the other such external drivers, this new idea of listing them with a short description and a link to vendor provided webpage is proposed!.</p><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em">So why again it is mentioned as ""Only drivers are covered that are contained in the official OpenStack project repository"" ???? - i 'm confused!.</p><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em">If this new proposal (short desc and external link) is again meant for only the drivers that are part of official openstack main repository - then why do we need this proposal itself?...</p><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em">I believe it originally triggered from the fact that we need a placeholder for listing the out-of-tree drivers. Since they are not part of the official openstack release/repository, they can not be documented or listed in the current existing documentation. Hence this idea of providing a placeholder with short desc and external link is proposed. Hence the out-of-tree vendors will maintain their plugin/drivers and detailed documentation.</p><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em">Pls. let me know if i missing something.</p></div></div></div></td></tr></tbody></table></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 9:18 AM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Vadivel,<div>We do have a blueprint in the docs-specs repo under review for driver documentation and I'd like to get your input. </div><div><a href="https://review.openstack.org/#/c/133372/" target="_blank">https://review.openstack.org/#/c/133372/</a><br></div><div><br></div><div>Here's a relevant excerpt:</div><div><br></div><div><div>The documentation team will fully document the reference drivers as</div><div>specified below and just add short sections for other drivers.</div><div><br></div><div>Guidelines for drivers that will be documented fully in the OpenStack</div><div>documentation:</div><div><br></div><div>* The complete solution must be open source and use standard hardware</div><div>* The driver must be part of the respective OpenStack repository</div><div>* The driver is considered one of the reference drivers</div><div><br></div><div>For documentation of other drivers, the following guidelines apply:</div><div><br></div><div>* The Configuration Reference will contain a small section for each</div><div>  driver, see below for details</div><div>* Only drivers are covered that are contained in the official</div><div>  OpenStack project repository for drivers (for example in the main</div><div>  project repository or the official "third party" repository).</div><div><br></div><div>With this policy, the docs team will document in their guides the</div><div>following:</div><div><br></div><div>* For cinder: volume drivers: document LVM only (TBD later: Samba,</div><div>  glusterfs); backup drivers: document swift (TBD later: ceph)</div><div>* For glance: Document local storage, cinder, and swift as backends</div><div>* For neutron: document ML2 plug-in with the mechanisms drivers</div><div>  OpenVSwitch and LinuxBridge</div><div>* For nova: document KVM (mostly), send Xen open source call for help</div><div>* For sahara: apache hadoop</div><div>* For trove: document all supported Open Source database engines like</div><div>  MySQL.</div></div><div><br></div><div>Let us know in the review itself if this answers your question about third-party drivers not in an official repository.</div><div>Thanks,</div><div>Anne</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 9:59 AM, Vadivel Poonathan <span dir="ltr"><<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Kyle and all,<div><br></div><div>Was there any conclusion in the design summit or the meetings afterward about splitting the vendor plugins/drivers from the mainstream neutron and documentation of out-of-tree plugins/drivers?... </div><div><br></div><div>Thanks,</div><div>Vad</div><div>--<div><br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan<br>
<<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
> Hi Kyle and Anne,<br>
><br>
> Thanks for the clarifications... understood and it makes sense.<br>
><br>
> However, per my understanding, the drivers (aka plugins) are meant to be<br>
> developed and supported by third-party vendors, outside of the OpenStack<br>
> community, and they are supposed to work as plug-n-play... they are not part<br>
> of the core OpenStack development, nor any of its components. If that is the<br>
> case, then why should OpenStack community include and maintain them as part<br>
> of it, for every release?...  Wouldnt it be enough to limit the scope with<br>
> the plugin framework and built-in drivers such as LinuxBridge or OVS etc?...<br>
> not extending to commercial vendors?...  (It is just a curious question,<br>
> forgive me if i missed something and correct me!).<br>
><br>
</span>You haven't misunderstood anything, we're in the process of splitting<br>
these things out, and this will be a prime focus of the Neutron design<br>
summit track at the upcoming summit.<br>
<br>
Thanks,<br>
Kyle<br>
<div><div><br>
> At the same time, IMHO, there must be some reference or a page within the<br>
> scope of OpenStack documentation (not necessarily the core docs, but some<br>
> wiki page or reference link or so - as Anne suggested) to mention the list<br>
> of the drivers/plugins supported as of given release and may be an external<br>
> link to know more details about the driver, if the link is provided by<br>
> respective vendor.<br>
><br>
><br>
> Anyway, besides my opinion, the wiki page similar to hypervisor driver would<br>
> be good for now atleast, until the direction/policy level decision is made<br>
> to maintain out-of-tree plugins/drivers.<br>
><br>
><br>
> Thanks,<br>
> Vad<br>
> --<br>
><br>
><br>
><br>
><br>
> On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana <<a href="mailto:edgar.magana@workday.com" target="_blank">edgar.magana@workday.com</a>><br>
> wrote:<br>
>><br>
>> I second Anne’s and Kyle comments. Actually, I like very much the wiki<br>
>> part to provide some visibility for out-of-tree plugins/drivers but not into<br>
>> the official documentation.<br>
>><br>
>> Thanks,<br>
>><br>
>> Edgar<br>
>><br>
>> From: Anne Gentle <<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>><br>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Date: Thursday, October 23, 2014 at 8:51 AM<br>
>> To: Kyle Mestery <<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>><br>
>> Cc: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update<br>
>> about new vendor plugin, but without code in repository?<br>
>><br>
>><br>
>><br>
>> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery <<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>><br>
>> wrote:<br>
>>><br>
>>> Vad:<br>
>>><br>
>>> The third-party CI is required for your upstream driver. I think<br>
>>> what's different from my reading of this thread is the question of<br>
>>> what is the requirement to have a driver listed in the upstream<br>
>>> documentation which is not in the upstream codebase. To my knowledge,<br>
>>> we haven't done this. Thus, IMHO, we should NOT be utilizing upstream<br>
>>> documentation to document drivers which are themselves not upstream.<br>
>>> When we split out the drivers which are currently upstream in neutron<br>
>>> into a separate repo, they will still be upstream. So my opinion here<br>
>>> is that if your driver is not upstream, it shouldn't be in the<br>
>>> upstream documentation. But I'd like to hear others opinions as well.<br>
>>><br>
>><br>
>> This is my sense as well.<br>
>><br>
>> The hypervisor drivers are documented on the wiki, sometimes they're<br>
>> in-tree, sometimes they're not, but the state of testing is documented on<br>
>> the wiki. I think we could take this approach for network and storage<br>
>> drivers as well.<br>
>><br>
>> <a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a><br>
>><br>
>> Anne<br>
>><br>
>>><br>
>>> Thanks,<br>
>>> Kyle<br>
>>><br>
>>> On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan<br>
>>> <<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
>>> > Kyle,<br>
>>> > Gentle reminder... when you get a chance!..<br>
>>> ><br>
>>> > Anne,<br>
>>> > In case, if i need to send it to different group or email-id to reach<br>
>>> > Kyle<br>
>>> > Mestery, pls. let me know. Thanks for your help.<br>
>>> ><br>
>>> > Regards,<br>
>>> > Vad<br>
>>> > --<br>
>>> ><br>
>>> ><br>
>>> > On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan<br>
>>> > <<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
>>> >><br>
>>> >> Hi Kyle,<br>
>>> >><br>
>>> >> Can you pls. comment on this discussion and confirm the requirements<br>
>>> >> for<br>
>>> >> getting out-of-tree mechanism_driver listed in the supported<br>
>>> >> plugin/driver<br>
>>> >> list of the Openstack Neutron docs.<br>
>>> >><br>
>>> >> Thanks,<br>
>>> >> Vad<br>
>>> >> --<br>
>>> >><br>
>>> >> On Mon, Oct 20, 2014 at 12:48 PM, Anne Gentle <<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>><br>
>>> >> wrote:<br>
>>> >>><br>
>>> >>><br>
>>> >>><br>
>>> >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan<br>
>>> >>> <<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
>>> >>>><br>
>>> >>>> Hi,<br>
>>> >>>><br>
>>> >>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton<br>
>>> >>>> >>>> <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>><br>
>>> >>>> >>>> wrote:<br>
>>> >>>> >>>>><br>
>>> >>>> >>>>> I think you will probably have to wait until after the summit<br>
>>> >>>> >>>>> so<br>
>>> >>>> >>>>> we can<br>
>>> >>>> >>>>> see the direction that will be taken with the rest of the<br>
>>> >>>> >>>>> in-tree<br>
>>> >>>> >>>>> drivers/plugins. It seems like we are moving towards removing<br>
>>> >>>> >>>>> all<br>
>>> >>>> >>>>> of them so<br>
>>> >>>> >>>>> we would definitely need a solution to documenting out-of-tree<br>
>>> >>>> >>>>> drivers as<br>
>>> >>>> >>>>> you suggested.<br>
>>> >>>><br>
>>> >>>> [Vad] while i 'm waiting for the conclusion on this subject, i 'm<br>
>>> >>>> trying<br>
>>> >>>> to setup the third-party CI/Test system and meet its requirements to<br>
>>> >>>> get my<br>
>>> >>>> mechanism_driver listed in the Kilo's documentation, in parallel.<br>
>>> >>>><br>
>>> >>>> Couple of questions/confirmations before i proceed further on this<br>
>>> >>>> direction...<br>
>>> >>>><br>
>>> >>>> 1) Is there anything more required other than the third-party<br>
>>> >>>> CI/Test<br>
>>> >>>> requirements ??.. like should I still need to go-through the entire<br>
>>> >>>> development process of submit/review/approval of the blue-print and<br>
>>> >>>> code of<br>
>>> >>>> my ML2 driver which was already developed and in-use?...<br>
>>> >>>><br>
>>> >>><br>
>>> >>> The neutron PTL Kyle Mestery can answer if there are any additional<br>
>>> >>> requirements.<br>
>>> >>><br>
>>> >>>><br>
>>> >>>> 2) Who is the authority to clarify and confirm the above (and how do<br>
>>> >>>> i<br>
>>> >>>> contact them)?...<br>
>>> >>><br>
>>> >>><br>
>>> >>> Elections just completed, and the newly elected PTL is Kyle Mestery,<br>
>>> >>><br>
>>> >>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/031433.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-March/031433.html</a>.<br>
>>> >>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> Thanks again for your inputs...<br>
>>> >>>><br>
>>> >>>> Regards,<br>
>>> >>>> Vad<br>
>>> >>>> --<br>
>>> >>>><br>
>>> >>>> On Tue, Oct 14, 2014 at 3:17 PM, Anne Gentle <<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>><br>
>>> >>>> wrote:<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan<br>
>>> >>>>> <<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
>>> >>>>>><br>
>>> >>>>>> Agreed on the requirements of test results to qualify the vendor<br>
>>> >>>>>> plugin to be listed in the upstream docs.<br>
>>> >>>>>> Is there any procedure/infrastructure currently available for this<br>
>>> >>>>>> purpose?..<br>
>>> >>>>>> Pls. fwd any link/pointers on those info.<br>
>>> >>>>>><br>
>>> >>>>><br>
>>> >>>>> Here's a link to the third-party testing setup information.<br>
>>> >>>>><br>
>>> >>>>> <a href="http://ci.openstack.org/third_party.html" target="_blank">http://ci.openstack.org/third_party.html</a><br>
>>> >>>>><br>
>>> >>>>> Feel free to keep asking questions as you dig deeper.<br>
>>> >>>>> Thanks,<br>
>>> >>>>> Anne<br>
>>> >>>>><br>
>>> >>>>>><br>
>>> >>>>>> Thanks,<br>
>>> >>>>>> Vad<br>
>>> >>>>>> --<br>
>>> >>>>>><br>
>>> >>>>>> On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki<br>
>>> >>>>>> <<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>><br>
>>> >>>>>> wrote:<br>
>>> >>>>>>><br>
>>> >>>>>>> I agree with Kevin and Kyle. Even if we decided to use separate<br>
>>> >>>>>>> tree<br>
>>> >>>>>>> for neutron<br>
>>> >>>>>>> plugins and drivers, they still will be regarded as part of the<br>
>>> >>>>>>> upstream.<br>
>>> >>>>>>> These plugins/drivers need to prove they are well integrated with<br>
>>> >>>>>>> Neutron master<br>
>>> >>>>>>> in some way and gating integration proves it is well tested and<br>
>>> >>>>>>> integrated.<br>
>>> >>>>>>> I believe it is a reasonable assumption and requirement that a<br>
>>> >>>>>>> vendor<br>
>>> >>>>>>> plugin/driver<br>
>>> >>>>>>> is listed in the upstream docs. This is a same kind of question<br>
>>> >>>>>>> as<br>
>>> >>>>>>> what vendor plugins<br>
>>> >>>>>>> are tested and worth documented in the upstream docs.<br>
>>> >>>>>>> I hope you work with the neutron team and run the third party<br>
>>> >>>>>>> requirements.<br>
>>> >>>>>>><br>
>>> >>>>>>> Thanks,<br>
>>> >>>>>>> Akihiro<br>
>>> >>>>>>><br>
>>> >>>>>>> On Tue, Oct 14, 2014 at 10:09 AM, Kyle Mestery<br>
>>> >>>>>>> <<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>><br>
>>> >>>>>>> wrote:<br>
>>> >>>>>>> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton<br>
>>> >>>>>>> > <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>><br>
>>> >>>>>>> > wrote:<br>
>>> >>>>>>> >>>The OpenStack dev and docs team dont have to worry about<br>
>>> >>>>>>> >>> gating/publishing/maintaining the vendor specific<br>
>>> >>>>>>> >>> plugins/drivers.<br>
>>> >>>>>>> >><br>
>>> >>>>>>> >> I disagree about the gating part. If a vendor wants to have a<br>
>>> >>>>>>> >> link<br>
>>> >>>>>>> >> that<br>
>>> >>>>>>> >> shows they are compatible with openstack, they should be<br>
>>> >>>>>>> >> reporting<br>
>>> >>>>>>> >> test<br>
>>> >>>>>>> >> results on all patches. A link to a vendor driver in the docs<br>
>>> >>>>>>> >> should signify<br>
>>> >>>>>>> >> some form of testing that the community is comfortable with.<br>
>>> >>>>>>> >><br>
>>> >>>>>>> > I agree with Kevin here. If you want to play upstream, in<br>
>>> >>>>>>> > whatever<br>
>>> >>>>>>> > form that takes by the end of Kilo, you have to work with the<br>
>>> >>>>>>> > existing<br>
>>> >>>>>>> > third-party requirements and team to take advantage of being a<br>
>>> >>>>>>> > part<br>
>>> >>>>>>> > of<br>
>>> >>>>>>> > things like upstream docs.<br>
>>> >>>>>>> ><br>
>>> >>>>>>> > Thanks,<br>
>>> >>>>>>> > Kyle<br>
>>> >>>>>>> ><br>
>>> >>>>>>> >> On Mon, Oct 13, 2014 at 11:33 AM, Vadivel Poonathan<br>
>>> >>>>>>> >> <<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> Hi,<br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> If the plan is to move ALL existing vendor specific<br>
>>> >>>>>>> >>> plugins/drivers<br>
>>> >>>>>>> >>> out-of-tree, then having a place-holder within the OpenStack<br>
>>> >>>>>>> >>> domain would<br>
>>> >>>>>>> >>> suffice, where the vendors can list their plugins/drivers<br>
>>> >>>>>>> >>> along<br>
>>> >>>>>>> >>> with their<br>
>>> >>>>>>> >>> documentation as how to install and use etc.<br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> The main Openstack Neutron documentation page can explain the<br>
>>> >>>>>>> >>> plugin<br>
>>> >>>>>>> >>> framework (ml2 type drivers, mechanism drivers, serviec<br>
>>> >>>>>>> >>> plugin<br>
>>> >>>>>>> >>> and so on)<br>
>>> >>>>>>> >>> and its purpose/usage etc, then provide a link to refer the<br>
>>> >>>>>>> >>> currently<br>
>>> >>>>>>> >>> supported vendor specific plugins/drivers for more details.<br>
>>> >>>>>>> >>> That<br>
>>> >>>>>>> >>> way the<br>
>>> >>>>>>> >>> documentation will be accurate to what is "in-tree" and limit<br>
>>> >>>>>>> >>> the<br>
>>> >>>>>>> >>> documentation of external plugins/drivers to have just a<br>
>>> >>>>>>> >>> reference link. So<br>
>>> >>>>>>> >>> its now vendor's responsibility to keep their  driver's<br>
>>> >>>>>>> >>> up-to-date and their<br>
>>> >>>>>>> >>> documentation accurate. The OpenStack dev and docs team dont<br>
>>> >>>>>>> >>> have<br>
>>> >>>>>>> >>> to worry<br>
>>> >>>>>>> >>> about gating/publishing/maintaining the vendor specific<br>
>>> >>>>>>> >>> plugins/drivers.<br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> The built-in drivers such as LinuxBridge or OpenVSwitch etc<br>
>>> >>>>>>> >>> can<br>
>>> >>>>>>> >>> continue<br>
>>> >>>>>>> >>> to be "in-tree" and their documentation will be part of main<br>
>>> >>>>>>> >>> Neutron's docs.<br>
>>> >>>>>>> >>> So the Neutron is guaranteed to work with built-in<br>
>>> >>>>>>> >>> plugins/drivers as per<br>
>>> >>>>>>> >>> the documentation and the user is informed to refer the<br>
>>> >>>>>>> >>> "external<br>
>>> >>>>>>> >>> vendor<br>
>>> >>>>>>> >>> plug-in page" for additional/specific plugins/drivers.<br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> Thanks,<br>
>>> >>>>>>> >>> Vad<br>
>>> >>>>>>> >>> --<br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> On Fri, Oct 10, 2014 at 8:10 PM, Anne Gentle<br>
>>> >>>>>>> >>> <<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>><br>
>>> >>>>>>> >>> wrote:<br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton<br>
>>> >>>>>>> >>>> <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>> I think you will probably have to wait until after the<br>
>>> >>>>>>> >>>>> summit<br>
>>> >>>>>>> >>>>> so we can<br>
>>> >>>>>>> >>>>> see the direction that will be taken with the rest of the<br>
>>> >>>>>>> >>>>> in-tree<br>
>>> >>>>>>> >>>>> drivers/plugins. It seems like we are moving towards<br>
>>> >>>>>>> >>>>> removing<br>
>>> >>>>>>> >>>>> all of them so<br>
>>> >>>>>>> >>>>> we would definitely need a solution to documenting<br>
>>> >>>>>>> >>>>> out-of-tree<br>
>>> >>>>>>> >>>>> drivers as<br>
>>> >>>>>>> >>>>> you suggested.<br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>> However, I think the minimum requirements for having a<br>
>>> >>>>>>> >>>>> driver<br>
>>> >>>>>>> >>>>> being<br>
>>> >>>>>>> >>>>> documented should be third-party testing of Neutron<br>
>>> >>>>>>> >>>>> patches.<br>
>>> >>>>>>> >>>>> Otherwise the<br>
>>> >>>>>>> >>>>> docs will become littered with a bunch of links to<br>
>>> >>>>>>> >>>>> drivers/plugins with no<br>
>>> >>>>>>> >>>>> indication of what actually works, which ultimately makes<br>
>>> >>>>>>> >>>>> Neutron look bad.<br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>> This is my line of thinking as well, expanded to "ultimately<br>
>>> >>>>>>> >>>> makes<br>
>>> >>>>>>> >>>> OpenStack docs look bad" -- a perception I want to avoid.<br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>> Keep the viewpoints coming. We have a crucial balancing act<br>
>>> >>>>>>> >>>> ahead: users<br>
>>> >>>>>>> >>>> need to trust docs and trust the drivers. Ultimately the<br>
>>> >>>>>>> >>>> responsibility for<br>
>>> >>>>>>> >>>> the docs is in the hands of the driver contributors so it<br>
>>> >>>>>>> >>>> seems<br>
>>> >>>>>>> >>>> those should<br>
>>> >>>>>>> >>>> be on a domain name where drivers control publishing and<br>
>>> >>>>>>> >>>> OpenStack docs are<br>
>>> >>>>>>> >>>> not a gatekeeper, quality checker, reviewer, or publisher.<br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>> We have documented the status of hypervisor drivers on an<br>
>>> >>>>>>> >>>> OpenStack wiki<br>
>>> >>>>>>> >>>> page. [1] To me, that type of list could be maintained on<br>
>>> >>>>>>> >>>> the<br>
>>> >>>>>>> >>>> wiki page<br>
>>> >>>>>>> >>>> better than in the docs themselves. Thoughts? Feelings? More<br>
>>> >>>>>>> >>>> discussion,<br>
>>> >>>>>>> >>>> please. And thank you for the responses so far.<br>
>>> >>>>>>> >>>> Anne<br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>> [1] <a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>> On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan<br>
>>> >>>>>>> >>>>> <<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> Hi Anne,<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> Thanks for your immediate response!...<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> Just to clarify... I have developed and maintaining a<br>
>>> >>>>>>> >>>>>> Neutron<br>
>>> >>>>>>> >>>>>> plug-in<br>
>>> >>>>>>> >>>>>> (ML2 mechanism_driver) since Grizzly and now it is<br>
>>> >>>>>>> >>>>>> up-to-date<br>
>>> >>>>>>> >>>>>> with Icehouse.<br>
>>> >>>>>>> >>>>>> But it was never listed nor part of the main Openstack<br>
>>> >>>>>>> >>>>>> releases. Now i would<br>
>>> >>>>>>> >>>>>> like to have my plugin mentioned as "supported<br>
>>> >>>>>>> >>>>>> plugin/mechanism_driver for<br>
>>> >>>>>>> >>>>>> so and so vendor equipments" in the <a href="http://docs.openstack.org" target="_blank">docs.openstack.org</a>,<br>
>>> >>>>>>> >>>>>> but<br>
>>> >>>>>>> >>>>>> without having<br>
>>> >>>>>>> >>>>>> the actual plugin code to be posted in the main Openstack<br>
>>> >>>>>>> >>>>>> GIT<br>
>>> >>>>>>> >>>>>> repository.<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> Reason is that I dont have plan/bandwidth to go thru the<br>
>>> >>>>>>> >>>>>> entire process<br>
>>> >>>>>>> >>>>>> of new plugin blue-print/development/review/testing etc as<br>
>>> >>>>>>> >>>>>> required by the<br>
>>> >>>>>>> >>>>>> Openstack development community. Bcos this is already<br>
>>> >>>>>>> >>>>>> developed, tested and<br>
>>> >>>>>>> >>>>>> released to some customers directly. Now I just want to<br>
>>> >>>>>>> >>>>>> get it<br>
>>> >>>>>>> >>>>>> to the<br>
>>> >>>>>>> >>>>>> official Openstack documentation, so that more people can<br>
>>> >>>>>>> >>>>>> get<br>
>>> >>>>>>> >>>>>> this and use.<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> The plugin package is made available to public from Ubuntu<br>
>>> >>>>>>> >>>>>> repository<br>
>>> >>>>>>> >>>>>> along with necessary documentation. So people can directly<br>
>>> >>>>>>> >>>>>> get<br>
>>> >>>>>>> >>>>>> it from<br>
>>> >>>>>>> >>>>>> Ubuntu repository and use it. All i need is to get listed<br>
>>> >>>>>>> >>>>>> in<br>
>>> >>>>>>> >>>>>> the<br>
>>> >>>>>>> >>>>>> <a href="http://docs.openstack.org" target="_blank">docs.openstack.org</a> so that people knows that it exists and<br>
>>> >>>>>>> >>>>>> can<br>
>>> >>>>>>> >>>>>> be used with<br>
>>> >>>>>>> >>>>>> any Openstack.<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> Pls. confrim whether this is something possible?...<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> Thanks again!..<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> Vad<br>
>>> >>>>>>> >>>>>> --<br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle<br>
>>> >>>>>>> >>>>>> <<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>><br>
>>> >>>>>>> >>>>>> wrote:<br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan<br>
>>> >>>>>>> >>>>>>> <<a href="mailto:vadivel.openstack@gmail.com" target="_blank">vadivel.openstack@gmail.com</a>> wrote:<br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> Hi,<br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> How to include a new vendor plug-in (aka<br>
>>> >>>>>>> >>>>>>>> mechanism_driver in<br>
>>> >>>>>>> >>>>>>>> ML2<br>
>>> >>>>>>> >>>>>>>> framework) into the Openstack documentation?.. In other<br>
>>> >>>>>>> >>>>>>>> words, is it<br>
>>> >>>>>>> >>>>>>>> possible to include a new plug-in in the Openstack<br>
>>> >>>>>>> >>>>>>>> documentation page<br>
>>> >>>>>>> >>>>>>>> without having the actual plug-in code as part of the<br>
>>> >>>>>>> >>>>>>>> Openstack neutron<br>
>>> >>>>>>> >>>>>>>> repository?... The actual plug-in is posted and<br>
>>> >>>>>>> >>>>>>>> available<br>
>>> >>>>>>> >>>>>>>> for the public to<br>
>>> >>>>>>> >>>>>>>> download as Ubuntu package. But i need to mention<br>
>>> >>>>>>> >>>>>>>> somewhere<br>
>>> >>>>>>> >>>>>>>> in the Openstack<br>
>>> >>>>>>> >>>>>>>> documentation that this new plugin is available for the<br>
>>> >>>>>>> >>>>>>>> public to use along<br>
>>> >>>>>>> >>>>>>>> with its documentation.<br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>> We definitely want you to include pointers to vendor<br>
>>> >>>>>>> >>>>>>> documentation in<br>
>>> >>>>>>> >>>>>>> the OpenStack docs, but I'd prefer make sure they're gate<br>
>>> >>>>>>> >>>>>>> tested before they<br>
>>> >>>>>>> >>>>>>> get listed on <a href="http://docs.openstack.org" target="_blank">docs.openstack.org</a>. Drivers change enough<br>
>>> >>>>>>> >>>>>>> release-to-release<br>
>>> >>>>>>> >>>>>>> that it's difficult to keep up maintenance.<br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>> Lately I've been talking to driver contributors<br>
>>> >>>>>>> >>>>>>> (hypervisor,<br>
>>> >>>>>>> >>>>>>> storage,<br>
>>> >>>>>>> >>>>>>> networking) about the out-of-tree changes possible. I'd<br>
>>> >>>>>>> >>>>>>> like<br>
>>> >>>>>>> >>>>>>> to encourage<br>
>>> >>>>>>> >>>>>>> even out-of-tree drivers to get listed, but to store<br>
>>> >>>>>>> >>>>>>> their<br>
>>> >>>>>>> >>>>>>> main documents<br>
>>> >>>>>>> >>>>>>> outside of <a href="http://docs.openstack.org" target="_blank">docs.openstack.org</a>, if they are gate-tested.<br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>> Anyone have other ideas here?<br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>> Looping in the OpenStack-docs mailing list also.<br>
>>> >>>>>>> >>>>>>> Anne<br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> Pls. provide some insights into whether it is<br>
>>> >>>>>>> >>>>>>>> possible?..<br>
>>> >>>>>>> >>>>>>>> and any<br>
>>> >>>>>>> >>>>>>>> further info on this?..<br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> Thanks,<br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> Vad<br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> --<br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> _______________________________________________<br>
>>> >>>>>>> >>>>>>>> OpenStack-dev mailing list<br>
>>> >>>>>>> >>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>> >>>>>>>><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>> _______________________________________________<br>
>>> >>>>>>> >>>>>>> OpenStack-dev mailing list<br>
>>> >>>>>>> >>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>> >>>>>>><br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> _______________________________________________<br>
>>> >>>>>>> >>>>>> OpenStack-dev mailing list<br>
>>> >>>>>>> >>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>> >>>>>><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>> --<br>
>>> >>>>>>> >>>>> Kevin Benton<br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>> _______________________________________________<br>
>>> >>>>>>> >>>>> OpenStack-dev mailing list<br>
>>> >>>>>>> >>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>> >>>>><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>> _______________________________________________<br>
>>> >>>>>>> >>>> OpenStack-dev mailing list<br>
>>> >>>>>>> >>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>> >>>><br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> _______________________________________________<br>
>>> >>>>>>> >>> OpenStack-dev mailing list<br>
>>> >>>>>>> >>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>> >>><br>
>>> >>>>>>> >><br>
>>> >>>>>>> >><br>
>>> >>>>>>> >><br>
>>> >>>>>>> >> --<br>
>>> >>>>>>> >> Kevin Benton<br>
>>> >>>>>>> >><br>
>>> >>>>>>> >> _______________________________________________<br>
>>> >>>>>>> >> OpenStack-dev mailing list<br>
>>> >>>>>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> >><br>
>>> >>>>>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>> >><br>
>>> >>>>>>> ><br>
>>> >>>>>>> > _______________________________________________<br>
>>> >>>>>>> > OpenStack-dev mailing list<br>
>>> >>>>>>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> ><br>
>>> >>>>>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>>><br>
>>> >>>>>>><br>
>>> >>>>>>><br>
>>> >>>>>>> --<br>
>>> >>>>>>> Akihiro Motoki <<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>><br>
>>> >>>>>>><br>
>>> >>>>>>> _______________________________________________<br>
>>> >>>>>>> OpenStack-dev mailing list<br>
>>> >>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>><br>
>>> >>>>>><br>
>>> >>>>>><br>
>>> >>>>>> _______________________________________________<br>
>>> >>>>>> OpenStack-dev mailing list<br>
>>> >>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>>><br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> _______________________________________________<br>
>>> >>>>> OpenStack-dev mailing list<br>
>>> >>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> _______________________________________________<br>
>>> >>>> OpenStack-dev mailing list<br>
>>> >>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>>><br>
>>> >>><br>
>>> >>><br>
>>> >>> _______________________________________________<br>
>>> >>> OpenStack-dev mailing list<br>
>>> >>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >>><br>
>>> >><br>
>>> ><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>