Open Stack

On Thu, Oct 23, 2014 at 9:49 AM, Edgar Magana <edgar.magana at 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.magana at workday.com>
> Date: Thursday, October 23, 2014 at 9:46 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>, Kyle Mestery <mestery at 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 <anne at openstack.org>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Thursday, October 23, 2014 at 8:51 AM
> To: Kyle Mestery <mestery at mestery.com>
> Cc: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <mestery at 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.openstack at 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.openstack at 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 <anne at openstack.org>
>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan
>> >>> <vadivel.openstack at gmail.com> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <
>> blak111 at 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 <anne at openstack.org>
>> wrote:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan
>> >>>>> <vadivel.openstack at 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 <
>> amotoki at 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 <
>> mestery at mestery.com>
>> >>>>>>> wrote:
>> >>>>>>> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton <
>> blak111 at 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.openstack at 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 <
>> anne at openstack.org>
>> >>>>>>> >>> wrote:
>> >>>>>>> >>>>
>> >>>>>>> >>>>
>> >>>>>>> >>>>
>> >>>>>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton
>> >>>>>>> >>>> <blak111 at 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.openstack at 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
>> >>>>>>> >>>>>> <anne at openstack.org>
>> >>>>>>> >>>>>> wrote:
>> >>>>>>> >>>>>>>
>> >>>>>>> >>>>>>>
>> >>>>>>> >>>>>>>
>> >>>>>>> >>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan
>> >>>>>>> >>>>>>> <vadivel.openstack at 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 at lists.openstack.org
>> >>>>>>> >>>>>>>>
>> >>>>>>> >>>>>>>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>> >>>>>>>>
>> >>>>>>> >>>>>>>
>> >>>>>>> >>>>>>>
>> >>>>>>> >>>>>>> _______________________________________________
>> >>>>>>> >>>>>>> OpenStack-dev mailing list
>> >>>>>>> >>>>>>> OpenStack-dev at lists.openstack.org
>> >>>>>>> >>>>>>>
>> >>>>>>> >>>>>>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>> >>>>>>>
>> >>>>>>> >>>>>>
>> >>>>>>> >>>>>>
>> >>>>>>> >>>>>> _______________________________________________
>> >>>>>>> >>>>>> OpenStack-dev mailing list
>> >>>>>>> >>>>>> OpenStack-dev at lists.openstack.org
>> >>>>>>> >>>>>>
>> >>>>>>> >>>>>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>> >>>>>>
>> >>>>>>> >>>>>
>> >>>>>>> >>>>>
>> >>>>>>> >>>>>
>> >>>>>>> >>>>> --
>> >>>>>>> >>>>> Kevin Benton
>> >>>>>>> >>>>>
>> >>>>>>> >>>>> _______________________________________________
>> >>>>>>> >>>>> OpenStack-dev mailing list
>> >>>>>>> >>>>> OpenStack-dev at lists.openstack.org
>> >>>>>>> >>>>>
>> >>>>>>> >>>>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>> >>>>>
>> >>>>>>> >>>>
>> >>>>>>> >>>>
>> >>>>>>> >>>> _______________________________________________
>> >>>>>>> >>>> OpenStack-dev mailing list
>> >>>>>>> >>>> OpenStack-dev at lists.openstack.org
>> >>>>>>> >>>>
>> >>>>>>> >>>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>> >>>>
>> >>>>>>> >>>
>> >>>>>>> >>>
>> >>>>>>> >>> _______________________________________________
>> >>>>>>> >>> OpenStack-dev mailing list
>> >>>>>>> >>> OpenStack-dev at lists.openstack.org
>> >>>>>>> >>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>> >>>
>> >>>>>>> >>
>> >>>>>>> >>
>> >>>>>>> >>
>> >>>>>>> >> --
>> >>>>>>> >> Kevin Benton
>> >>>>>>> >>
>> >>>>>>> >> _______________________________________________
>> >>>>>>> >> OpenStack-dev mailing list
>> >>>>>>> >> OpenStack-dev at lists.openstack.org
>> >>>>>>> >>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>> >>
>> >>>>>>> >
>> >>>>>>> > _______________________________________________
>> >>>>>>> > OpenStack-dev mailing list
>> >>>>>>> > OpenStack-dev at lists.openstack.org
>> >>>>>>> >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Akihiro Motoki <amotoki at gmail.com>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> OpenStack-dev mailing list
>> >>>>>>> OpenStack-dev at lists.openstack.org
>> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> OpenStack-dev mailing list
>> >>>>>> OpenStack-dev at lists.openstack.org
>> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OpenStack-dev mailing list
>> >>>>> OpenStack-dev at lists.openstack.org
>> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> OpenStack-dev mailing list
>> >>>> OpenStack-dev at lists.openstack.org
>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> OpenStack-dev mailing list
>> >>> OpenStack-dev at lists.openstack.org
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/6bccff84/attachment-0001.html>