<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 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 class="">On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan<br>
<<a href="mailto:vadivel.openstack@gmail.com">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 class="HOEnZb"><div class="h5"><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">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">anne@openstack.org</a>><br>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">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">mestery@mestery.com</a>><br>
>> Cc: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">amotoki@gmail.com</a>><br>
>>> >>>>>>><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>
>>> >>>>>><br>
>>> >>>>>><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>
>>> >>>>><br>
>>> >>>>><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>
>>> >>>><br>
>>> >>>><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>
>>> >>><br>
>>> >>><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>
>>> >><br>
>>> ><br>
>><br>
>><br>
>><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>
><br>
</div></div></blockquote></div><br></div>