Open Stack

Hi Kyle and all,

Was there any conclusion in the design summit or the meetings afterward
about splitting the vendor plugins/drivers from the mainstream neutron and
documentation of out-of-tree plugins/drivers?...

Thanks,
Vad
--


On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery <mestery at mestery.com> wrote:

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