On Thu, Oct 23, 2014 at 9:49 AM, Edgar Magana <edgar.mag...@workday.com> wrote:
> I forgot to mention that I can help to coordinate the creation and > maintenance of the wiki for non-upstreamed drivers for Neutron. > >>[vad] Edgar, that would be nice!... but not sure whether it has to wait till the outcome of the design discussion on this topic in the upcoming summit??!... Thanks, Vad -- > We need to be sure that we DO NOT confuse users with the current > information here: > https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers > > I have been maintaining that wiki and I would like to keep just for > upstreamed vendor-specific plugins/drivers. > > Edgar > > From: Edgar Magana <edgar.mag...@workday.com> > Date: Thursday, October 23, 2014 at 9:46 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org>, Kyle Mestery <mest...@mestery.com> > > Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update > about new vendor plugin, but without code in repository? > > 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
