-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/12/14 16:59, Vadivel Poonathan wrote: > 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?...
It's expected that the following spec that covers the plugins split to be approved and implemented during Kilo: https://review.openstack.org/134680 > > Thanks, Vad -- > > > On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery > <mest...@mestery.com <mailto:mest...@mestery.com>> wrote: > > On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan > <vadivel.openst...@gmail.com <mailto:vadivel.openst...@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.mag...@workday.com <mailto:edgar.mag...@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 <a...@openstack.org >>> <mailto:a...@openstack.org>> Reply-To: "OpenStack Development >>> Mailing List (not for usage > questions)" >>> <openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org>> >>> Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery >>> <mest...@mestery.com <mailto:mest...@mestery.com>> Cc: >>> "OpenStack Development Mailing List (not for usage questions)" >>> <openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org>> >>> Subject: Re: [openstack-dev] [Neutron] Neutron documentation >>> to > update >>> about new vendor plugin, but without code in repository? >>> >>> >>> >>> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery > <mest...@mestery.com <mailto:mest...@mestery.com>> >>> wrote: >>>> >>>> Vad: >>>> >>>> The third-party CI is required for your upstream driver. I >>>> think what's different from my reading of this thread is the >>>> question of what is the requirement to have a driver listed >>>> in the upstream documentation which is not in the upstream >>>> codebase. To my > knowledge, >>>> we haven't done this. Thus, IMHO, we should NOT be utilizing > upstream >>>> documentation to document drivers which are themselves not >>>> upstream. When we split out the drivers which are currently >>>> upstream in > neutron >>>> into a separate repo, they will still be upstream. So my >>>> opinion > here >>>> is that if your driver is not upstream, it shouldn't be in >>>> the upstream documentation. But I'd like to hear others >>>> opinions as > well. >>>> >>> >>> This is my sense as well. >>> >>> The hypervisor drivers are documented on the wiki, sometimes >>> they're in-tree, sometimes they're not, but the state of >>> testing is > documented on >>> the wiki. I think we could take this approach for network and >>> storage drivers as well. >>> >>> https://wiki.openstack.org/wiki/HypervisorSupportMatrix >>> >>> Anne >>> >>>> >>>> Thanks, Kyle >>>> >>>> On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan >>>> <vadivel.openst...@gmail.com > <mailto:vadivel.openst...@gmail.com>> wrote: >>>>> Kyle, Gentle reminder... when you get a chance!.. >>>>> >>>>> Anne, In case, if i need to send it to different group or >>>>> email-id > to reach >>>>> Kyle Mestery, pls. let me know. Thanks for your help. >>>>> >>>>> Regards, Vad -- >>>>> >>>>> >>>>> On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan >>>>> <vadivel.openst...@gmail.com > <mailto:vadivel.openst...@gmail.com>> wrote: >>>>>> >>>>>> Hi Kyle, >>>>>> >>>>>> Can you pls. comment on this discussion and confirm the > requirements >>>>>> for getting out-of-tree mechanism_driver listed in the >>>>>> supported plugin/driver list of the Openstack Neutron >>>>>> docs. >>>>>> >>>>>> Thanks, Vad -- >>>>>> >>>>>> On Mon, Oct 20, 2014 at 12:48 PM, Anne Gentle > <a...@openstack.org <mailto:a...@openstack.org>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan >>>>>>> <vadivel.openst...@gmail.com > <mailto:vadivel.openst...@gmail.com>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>>>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin >>>>>>>>>>>> Benton <blak...@gmail.com >>>>>>>>>>>> <mailto:blak...@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I think you will probably have to wait >>>>>>>>>>>>> until after > the summit >>>>>>>>>>>>> so we can see the direction that will be >>>>>>>>>>>>> taken with the rest of the in-tree >>>>>>>>>>>>> drivers/plugins. It seems like we are >>>>>>>>>>>>> moving towards > removing >>>>>>>>>>>>> all of them so we would definitely need a >>>>>>>>>>>>> solution to documenting > out-of-tree >>>>>>>>>>>>> drivers as you suggested. >>>>>>>> >>>>>>>> [Vad] while i 'm waiting for the conclusion on this > subject, i 'm >>>>>>>> trying to setup the third-party CI/Test system and >>>>>>>> meet its > requirements to >>>>>>>> get my mechanism_driver listed in the Kilo's >>>>>>>> documentation, in > parallel. >>>>>>>> >>>>>>>> Couple of questions/confirmations before i proceed >>>>>>>> further > on this >>>>>>>> direction... >>>>>>>> >>>>>>>> 1) Is there anything more required other than the >>>>>>>> third-party CI/Test requirements ??.. like should I >>>>>>>> still need to go-through > the entire >>>>>>>> development process of submit/review/approval of the > blue-print and >>>>>>>> code of my ML2 driver which was already developed and >>>>>>>> in-use?... >>>>>>>> >>>>>>> >>>>>>> The neutron PTL Kyle Mestery can answer if there are >>>>>>> any > additional >>>>>>> requirements. >>>>>>> >>>>>>>> >>>>>>>> 2) Who is the authority to clarify and confirm the >>>>>>>> above > (and how do >>>>>>>> i contact them)?... >>>>>>> >>>>>>> >>>>>>> Elections just completed, and the newly elected PTL is >>>>>>> Kyle > Mestery, >>>>>>> >>>>>>> > http://lists.openstack.org/pipermail/openstack-dev/2014-March/031433.html. > > >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks again for your inputs... >>>>>>>> >>>>>>>> Regards, Vad -- >>>>>>>> >>>>>>>> On Tue, Oct 14, 2014 at 3:17 PM, Anne Gentle > <a...@openstack.org <mailto:a...@openstack.org>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan >>>>>>>>> <vadivel.openst...@gmail.com > <mailto:vadivel.openst...@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> Agreed on the requirements of test results to >>>>>>>>>> qualify the > vendor >>>>>>>>>> plugin to be listed in the upstream docs. Is >>>>>>>>>> there any procedure/infrastructure currently >>>>>>>>>> available > for this >>>>>>>>>> purpose?.. Pls. fwd any link/pointers on those >>>>>>>>>> info. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Here's a link to the third-party testing setup >>>>>>>>> information. >>>>>>>>> >>>>>>>>> http://ci.openstack.org/third_party.html >>>>>>>>> >>>>>>>>> Feel free to keep asking questions as you dig >>>>>>>>> deeper. Thanks, Anne >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, Vad -- >>>>>>>>>> >>>>>>>>>> On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki >>>>>>>>>> <amot...@gmail.com <mailto:amot...@gmail.com>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I agree with Kevin and Kyle. Even if we decided >>>>>>>>>>> to use > separate >>>>>>>>>>> tree for neutron plugins and drivers, they >>>>>>>>>>> still will be regarded as part > of the >>>>>>>>>>> upstream. These plugins/drivers need to prove >>>>>>>>>>> they are well > integrated with >>>>>>>>>>> Neutron master in some way and gating >>>>>>>>>>> integration proves it is well > tested and >>>>>>>>>>> integrated. I believe it is a reasonable >>>>>>>>>>> assumption and requirement > that a >>>>>>>>>>> vendor plugin/driver is listed in the upstream >>>>>>>>>>> docs. This is a same kind of > question >>>>>>>>>>> as what vendor plugins are tested and worth >>>>>>>>>>> documented in the upstream docs. I hope you >>>>>>>>>>> work with the neutron team and run the third > party >>>>>>>>>>> requirements. >>>>>>>>>>> >>>>>>>>>>> Thanks, Akihiro >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 14, 2014 at 10:09 AM, Kyle Mestery >>>>>>>>>>> <mest...@mestery.com >>>>>>>>>>> <mailto:mest...@mestery.com>> wrote: >>>>>>>>>>>> On Mon, Oct 13, 2014 at 6:44 PM, Kevin >>>>>>>>>>>> Benton <blak...@gmail.com >>>>>>>>>>>> <mailto:blak...@gmail.com>> wrote: >>>>>>>>>>>>>> The OpenStack dev and docs team dont have >>>>>>>>>>>>>> to worry about >>>>>>>>>>>>>> gating/publishing/maintaining the vendor >>>>>>>>>>>>>> specific plugins/drivers. >>>>>>>>>>>>> >>>>>>>>>>>>> I disagree about the gating part. If a >>>>>>>>>>>>> vendor wants > to have a >>>>>>>>>>>>> link that shows they are compatible with >>>>>>>>>>>>> openstack, they should be reporting test >>>>>>>>>>>>> results on all patches. A link to a vendor >>>>>>>>>>>>> driver in > the docs >>>>>>>>>>>>> should signify some form of testing that >>>>>>>>>>>>> the community is > comfortable with. >>>>>>>>>>>>> >>>>>>>>>>>> I agree with Kevin here. If you want to play >>>>>>>>>>>> upstream, in whatever form that takes by the >>>>>>>>>>>> end of Kilo, you have to work > with the >>>>>>>>>>>> existing third-party requirements and team to >>>>>>>>>>>> take advantage of > being a >>>>>>>>>>>> part of things like upstream docs. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Kyle >>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Oct 13, 2014 at 11:33 AM, Vadivel >>>>>>>>>>>>> Poonathan <vadivel.openst...@gmail.com > <mailto:vadivel.openst...@gmail.com>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the plan is to move ALL existing >>>>>>>>>>>>>> vendor specific plugins/drivers >>>>>>>>>>>>>> out-of-tree, then having a place-holder >>>>>>>>>>>>>> within the > OpenStack >>>>>>>>>>>>>> domain would suffice, where the vendors >>>>>>>>>>>>>> can list their > plugins/drivers >>>>>>>>>>>>>> along with their documentation as how to >>>>>>>>>>>>>> install and use etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The main Openstack Neutron documentation >>>>>>>>>>>>>> page can > explain the >>>>>>>>>>>>>> plugin framework (ml2 type drivers, >>>>>>>>>>>>>> mechanism drivers, serviec plugin and so >>>>>>>>>>>>>> on) and its purpose/usage etc, then >>>>>>>>>>>>>> provide a link to > refer the >>>>>>>>>>>>>> currently supported vendor specific >>>>>>>>>>>>>> plugins/drivers for more > details. >>>>>>>>>>>>>> That way the documentation will be >>>>>>>>>>>>>> accurate to what is "in-tree" > and limit >>>>>>>>>>>>>> the documentation of external >>>>>>>>>>>>>> plugins/drivers to have just a reference >>>>>>>>>>>>>> link. So its now vendor's responsibility >>>>>>>>>>>>>> to keep their driver's up-to-date and >>>>>>>>>>>>>> their documentation accurate. The >>>>>>>>>>>>>> OpenStack dev and docs > team dont >>>>>>>>>>>>>> have to worry about >>>>>>>>>>>>>> gating/publishing/maintaining the vendor >>>>>>>>>>>>>> specific plugins/drivers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The built-in drivers such as LinuxBridge >>>>>>>>>>>>>> or > OpenVSwitch etc >>>>>>>>>>>>>> can continue to be "in-tree" and their >>>>>>>>>>>>>> documentation will be part > of main >>>>>>>>>>>>>> Neutron's docs. So the Neutron is >>>>>>>>>>>>>> guaranteed to work with built-in >>>>>>>>>>>>>> plugins/drivers as per the documentation >>>>>>>>>>>>>> and the user is informed to refer the >>>>>>>>>>>>>> "external vendor plug-in page" for >>>>>>>>>>>>>> additional/specific plugins/drivers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, Vad -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Oct 10, 2014 at 8:10 PM, Anne >>>>>>>>>>>>>> Gentle <a...@openstack.org >>>>>>>>>>>>>> <mailto:a...@openstack.org>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin >>>>>>>>>>>>>>> Benton <blak...@gmail.com >>>>>>>>>>>>>>> <mailto:blak...@gmail.com>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think you will probably have to >>>>>>>>>>>>>>>> wait until after the summit so we >>>>>>>>>>>>>>>> can see the direction that will be >>>>>>>>>>>>>>>> taken with the rest > of the >>>>>>>>>>>>>>>> in-tree drivers/plugins. It seems >>>>>>>>>>>>>>>> like we are moving towards removing >>>>>>>>>>>>>>>> all of them so we would definitely >>>>>>>>>>>>>>>> need a solution to documenting >>>>>>>>>>>>>>>> out-of-tree drivers as you >>>>>>>>>>>>>>>> suggested. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, I think the minimum >>>>>>>>>>>>>>>> requirements for having a driver >>>>>>>>>>>>>>>> being documented should be >>>>>>>>>>>>>>>> third-party testing of Neutron >>>>>>>>>>>>>>>> patches. Otherwise the docs will >>>>>>>>>>>>>>>> become littered with a bunch of links >>>>>>>>>>>>>>>> to drivers/plugins with no indication >>>>>>>>>>>>>>>> of what actually works, which > ultimately makes >>>>>>>>>>>>>>>> Neutron look bad. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is my line of thinking as well, >>>>>>>>>>>>>>> expanded to > "ultimately >>>>>>>>>>>>>>> makes OpenStack docs look bad" -- a >>>>>>>>>>>>>>> perception I want to > avoid. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Keep the viewpoints coming. We have a >>>>>>>>>>>>>>> crucial > balancing act >>>>>>>>>>>>>>> ahead: users need to trust docs and >>>>>>>>>>>>>>> trust the drivers. > Ultimately the >>>>>>>>>>>>>>> responsibility for the docs is in the >>>>>>>>>>>>>>> hands of the driver contributors > so it >>>>>>>>>>>>>>> seems those should be on a domain name >>>>>>>>>>>>>>> where drivers control > publishing and >>>>>>>>>>>>>>> OpenStack docs are not a gatekeeper, >>>>>>>>>>>>>>> quality checker, reviewer, or > publisher. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have documented the status of >>>>>>>>>>>>>>> hypervisor drivers > on an >>>>>>>>>>>>>>> OpenStack wiki page. [1] To me, that >>>>>>>>>>>>>>> type of list could be > maintained on >>>>>>>>>>>>>>> the wiki page better than in the docs >>>>>>>>>>>>>>> themselves. Thoughts? > Feelings? More >>>>>>>>>>>>>>> discussion, please. And thank you for >>>>>>>>>>>>>>> the responses so far. Anne >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] > https://wiki.openstack.org/wiki/HypervisorSupportMatrix >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Oct 10, 2014 at 1:28 PM, >>>>>>>>>>>>>>>> Vadivel Poonathan >>>>>>>>>>>>>>>> <vadivel.openst...@gmail.com > <mailto:vadivel.openst...@gmail.com>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Anne, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for your immediate >>>>>>>>>>>>>>>>> response!... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Just to clarify... I have developed >>>>>>>>>>>>>>>>> and maintaining a Neutron plug-in >>>>>>>>>>>>>>>>> (ML2 mechanism_driver) since >>>>>>>>>>>>>>>>> Grizzly and now it is up-to-date >>>>>>>>>>>>>>>>> with Icehouse. But it was never >>>>>>>>>>>>>>>>> listed nor part of the main > Openstack >>>>>>>>>>>>>>>>> releases. Now i would like to have >>>>>>>>>>>>>>>>> my plugin mentioned as "supported >>>>>>>>>>>>>>>>> plugin/mechanism_driver for so and >>>>>>>>>>>>>>>>> so vendor equipments" in the > docs.openstack.org <http://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 >>>>>>>>>>>>>>>>> <http://docs.openstack.org> so > that people knows that it exists and >>>>>>>>>>>>>>>>> can be used with any Openstack. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Pls. confrim whether this is >>>>>>>>>>>>>>>>> something possible?... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks again!.. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Vad -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Oct 10, 2014 at 12:18 PM, >>>>>>>>>>>>>>>>> Anne Gentle <a...@openstack.org >>>>>>>>>>>>>>>>> <mailto:a...@openstack.org>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, >>>>>>>>>>>>>>>>>> Vadivel Poonathan >>>>>>>>>>>>>>>>>> <vadivel.openst...@gmail.com > <mailto:vadivel.openst...@gmail.com>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> How to include a new vendor >>>>>>>>>>>>>>>>>>> plug-in (aka mechanism_driver >>>>>>>>>>>>>>>>>>> in ML2 framework) into the >>>>>>>>>>>>>>>>>>> Openstack documentation?.. > In other >>>>>>>>>>>>>>>>>>> words, is it possible to >>>>>>>>>>>>>>>>>>> include a new plug-in in the >>>>>>>>>>>>>>>>>>> Openstack documentation page >>>>>>>>>>>>>>>>>>> without having the actual >>>>>>>>>>>>>>>>>>> plug-in code as part > of the >>>>>>>>>>>>>>>>>>> Openstack neutron >>>>>>>>>>>>>>>>>>> repository?... The actual >>>>>>>>>>>>>>>>>>> plug-in is posted and >>>>>>>>>>>>>>>>>>> available for the public to >>>>>>>>>>>>>>>>>>> download as Ubuntu package. But >>>>>>>>>>>>>>>>>>> i need to mention somewhere in >>>>>>>>>>>>>>>>>>> the Openstack documentation >>>>>>>>>>>>>>>>>>> that this new plugin is >>>>>>>>>>>>>>>>>>> available > for the >>>>>>>>>>>>>>>>>>> public to use along with its >>>>>>>>>>>>>>>>>>> documentation. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We definitely want you to include >>>>>>>>>>>>>>>>>> pointers to vendor documentation >>>>>>>>>>>>>>>>>> in the OpenStack docs, but I'd >>>>>>>>>>>>>>>>>> prefer make sure > they're gate >>>>>>>>>>>>>>>>>> tested before they get listed on >>>>>>>>>>>>>>>>>> docs.openstack.org > <http://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 > <http://docs.openstack.org>, if they are gate-tested. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Anyone have other ideas here? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Looping in the OpenStack-docs >>>>>>>>>>>>>>>>>> mailing list also. Anne >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Pls. provide some insights into >>>>>>>>>>>>>>>>>>> whether it is possible?.. and >>>>>>>>>>>>>>>>>>> any further info on this?.. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Vad >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>>>>>>>>> OpenStack-dev@lists.openstack.org > >>>>>>>>>>>>>>>>>>> <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>>>>>>>> OpenStack-dev@lists.openstack.org > >>>>>>>>>>>>>>>>>> <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Kevin Benton >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>> >>>>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- Kevin Benton >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> >>>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>>> >>>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> >>>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>>> >>>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- Akihiro Motoki <amot...@gmail.com > <mailto:amot...@gmail.com>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> >>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OpenStack-dev mailing list >>>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OpenStack-dev mailing list >>>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenStack-dev mailing list >>>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenStack-dev mailing list >>>>>>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>> >>>>> >>> >>> >>> >>> _______________________________________________ OpenStack-dev >>> mailing list OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> >> >> > > > > > _______________________________________________ OpenStack-dev > mailing list OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUgaSxAAoJEC5aWaUY1u57jIsIAJh93uqzvX0j4mpVAmBCEB/M mei9eQZNCTsWBEMnwP6b2b3Xtc1bjzhSc2nQjAzu+MJeIrckcozgXtPKR2JmUT7u 2H03oS6DZT2ZqnvKLqvend35tcG/p/sNQ88js+C5efFC+x5xy3Taxpj4eFsOfD4L DuzR7Gl5HlblGt9NRNGdmG9SN1rk2/cydgXK05lR+1/prQUkIlnPIs+3ySJmuEKN Tm6qVVP8zQDp8Vrvhy2IyjuSzOq4v63oFjNYPa7biXWRPRA2CSmo/zpRYpOgdo3s BtFKi+MuSKYK9Ox2n0b6jcrkqwebFr14O5sgDk7nIhPgrTjXKdbGndF/zWJK/b8= =t1iZ -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
