Open Stack

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
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/eaf25607/attachment.html>