[openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?

Ihar Hrachyshka ihrachys at redhat.com
Fri Dec 5 12:27:29 UTC 2014 

-----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
> <mestery at mestery.com <mailto:mestery at mestery.com>> wrote:
> 
> On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan 
> <vadivel.openstack at gmail.com <mailto: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 <mailto: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
>>> <mailto:anne at openstack.org>> Reply-To: "OpenStack Development
>>> Mailing List (not for usage
> questions)"
>>> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
>>> Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery
>>> <mestery at mestery.com <mailto:mestery at mestery.com>> Cc:
>>> "OpenStack Development Mailing List (not for usage questions)" 
>>> <openstack-dev at lists.openstack.org
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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 <mailto:anne at openstack.org>>
>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan 
>>>>>>> <vadivel.openstack at gmail.com
> <mailto:vadivel.openstack at gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>>>>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin
>>>>>>>>>>>> Benton <blak111 at gmail.com
>>>>>>>>>>>> <mailto: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 <mailto:anne at openstack.org>>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan 
>>>>>>>>> <vadivel.openstack at gmail.com
> <mailto: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 <mailto: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
>>>>>>>>>>> <mailto:mestery at mestery.com>> wrote:
>>>>>>>>>>>> On Mon, Oct 13, 2014 at 6:44 PM, Kevin
>>>>>>>>>>>> Benton <blak111 at gmail.com
>>>>>>>>>>>> <mailto: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
> <mailto: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
>>>>>>>>>>>>>> <mailto:anne at openstack.org>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin
>>>>>>>>>>>>>>> Benton <blak111 at gmail.com
>>>>>>>>>>>>>>> <mailto: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
> <mailto: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 <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 <anne at openstack.org
>>>>>>>>>>>>>>>>> <mailto:anne at openstack.org>> 
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Fri, Oct 10, 2014 at 2:11 PM,
>>>>>>>>>>>>>>>>>> Vadivel Poonathan 
>>>>>>>>>>>>>>>>>> <vadivel.openstack at gmail.com
> <mailto: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
> <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 at lists.openstack.org
>
>>>>>>>>>>>>>>>>>>> 
<mailto: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
>
>>>>>>>>>>>>>>>>>> 
<mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:OpenStack-dev at lists.openstack.org>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- Akihiro Motoki <amotoki at gmail.com
> <mailto:amotoki at gmail.com>>
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>
>>>>>>>>>>> 
>>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>>>> OpenStack-dev at lists.openstack.org
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> 
-----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-----

More information about the OpenStack-dev mailing list