Open Stack

On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan
<vadivel.openstack at 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.magana at 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 <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
>>
>