Hi Kyle and all, 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?...
Thanks, Vad -- On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery <mest...@mestery.com> wrote: > On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan > <vadivel.openst...@gmail.com> wrote: > > Hi Kyle and Anne, > > > > Thanks for the clarifications... understood and it makes sense. > > > > However, per my understanding, the drivers (aka plugins) are meant to be > > developed and supported by third-party vendors, outside of the OpenStack > > community, and they are supposed to work as plug-n-play... they are not > part > > of the core OpenStack development, nor any of its components. If that is > the > > case, then why should OpenStack community include and maintain them as > part > > of it, for every release?... Wouldnt it be enough to limit the scope > with > > the plugin framework and built-in drivers such as LinuxBridge or OVS > etc?... > > not extending to commercial vendors?... (It is just a curious question, > > forgive me if i missed something and correct me!). > > > You haven't misunderstood anything, we're in the process of splitting > these things out, and this will be a prime focus of the Neutron design > summit track at the upcoming summit. > > Thanks, > Kyle > > > At the same time, IMHO, there must be some reference or a page within the > > scope of OpenStack documentation (not necessarily the core docs, but some > > wiki page or reference link or so - as Anne suggested) to mention the > list > > of the drivers/plugins supported as of given release and may be an > external > > link to know more details about the driver, if the link is provided by > > respective vendor. > > > > > > Anyway, besides my opinion, the wiki page similar to hypervisor driver > would > > be good for now atleast, until the direction/policy level decision is > made > > to maintain out-of-tree plugins/drivers. > > > > > > Thanks, > > Vad > > -- > > > > > > > > > > On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana <edgar.mag...@workday.com> > > wrote: > >> > >> I second Anne’s and Kyle comments. Actually, I like very much the wiki > >> part to provide some visibility for out-of-tree plugins/drivers but not > into > >> the official documentation. > >> > >> Thanks, > >> > >> Edgar > >> > >> From: Anne Gentle <a...@openstack.org> > >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" > >> <openstack-dev@lists.openstack.org> > >> Date: Thursday, October 23, 2014 at 8:51 AM > >> To: Kyle Mestery <mest...@mestery.com> > >> Cc: "OpenStack Development Mailing List (not for usage questions)" > >> <openstack-dev@lists.openstack.org> > >> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update > >> about new vendor plugin, but without code in repository? > >> > >> > >> > >> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery <mest...@mestery.com> > >> wrote: > >>> > >>> Vad: > >>> > >>> The third-party CI is required for your upstream driver. I think > >>> what's different from my reading of this thread is the question of > >>> what is the requirement to have a driver listed in the upstream > >>> documentation which is not in the upstream codebase. To my knowledge, > >>> we haven't done this. Thus, IMHO, we should NOT be utilizing upstream > >>> documentation to document drivers which are themselves not upstream. > >>> When we split out the drivers which are currently upstream in neutron > >>> into a separate repo, they will still be upstream. So my opinion here > >>> is that if your driver is not upstream, it shouldn't be in the > >>> upstream documentation. But I'd like to hear others opinions as well. > >>> > >> > >> This is my sense as well. > >> > >> The hypervisor drivers are documented on the wiki, sometimes they're > >> in-tree, sometimes they're not, but the state of testing is documented > on > >> the wiki. I think we could take this approach for network and storage > >> drivers as well. > >> > >> https://wiki.openstack.org/wiki/HypervisorSupportMatrix > >> > >> Anne > >> > >>> > >>> Thanks, > >>> Kyle > >>> > >>> On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan > >>> <vadivel.openst...@gmail.com> wrote: > >>> > 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> > >>> >>>> >>>> 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 > >> > > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev