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
