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

Vadivel Poonathan vadivel.openstack at gmail.com
Tue Oct 21 15:51:32 UTC 2014


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
>> <blak111 at gmail.com>> wrote:>>>>>>>>>> I think you will probably have to
>> wait until after the summit so we can>>>>> see the direction that will be
>> taken with the rest of the in-tree>>>>> drivers/plugins. It seems like we
>> are moving towards removing all of them so>>>>> we would definitely need a
>> solution to documenting out-of-tree drivers as>>>>> you suggested.*
>>
>> [Vad] while i 'm waiting for the conclusion on this subject, i 'm trying
>> to setup the third-party CI/Test system and meet its requirements to get my
>> mechanism_driver listed in the Kilo's documentation, in parallel.
>>
>> Couple of questions/confirmations before i proceed further on this
>> direction...
>>
>> 1) Is there anything more required other than the third-party CI/Test
>> requirements ??.. like should I still need to go-through the entire
>> development process of submit/review/approval of the blue-print and code of
>> my ML2 driver which was already developed and in-use?...
>>
>>
> The neutron PTL Kyle Mestery can answer if there are any additional
> requirements.
>
>
>> 2) Who is the authority to clarify and confirm the above (and how do i
>> contact them)?...
>>
>
> Elections just completed, and the newly elected PTL is Kyle Mestery,
> http://lists.openstack.org/pipermail/openstack-dev/2014-March/031433.html
> .
>
>
>>
>> Thanks again for your inputs...
>>
>> Regards,
>> Vad
>> --
>>
>> On Tue, Oct 14, 2014 at 3:17 PM, Anne Gentle <anne at openstack.org> wrote:
>>
>>>
>>>
>>> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan <
>>> vadivel.openstack at gmail.com> wrote:
>>>
>>>> Agreed on the requirements of test results to qualify the vendor plugin
>>>> to be listed in the upstream docs.
>>>> Is there any procedure/infrastructure currently available for this
>>>> purpose?..
>>>> Pls. fwd any link/pointers on those info.
>>>>
>>>>
>>> Here's a link to the third-party testing setup information.
>>>
>>> http://ci.openstack.org/third_party.html
>>>
>>> Feel free to keep asking questions as you dig deeper.
>>> Thanks,
>>> Anne
>>>
>>>
>>>> Thanks,
>>>> Vad
>>>> --
>>>>
>>>> On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki <amotoki at gmail.com>
>>>> wrote:
>>>>
>>>>> I agree with Kevin and Kyle. Even if we decided to use separate tree
>>>>> for neutron
>>>>> plugins and drivers, they still will be regarded as part of the
>>>>> upstream.
>>>>> These plugins/drivers need to prove they are well integrated with
>>>>> Neutron master
>>>>> in some way and gating integration proves it is well tested and
>>>>> integrated.
>>>>> I believe it is a reasonable assumption and requirement that a vendor
>>>>> plugin/driver
>>>>> is listed in the upstream docs. This is a same kind of question as
>>>>> what vendor plugins
>>>>> are tested and worth documented in the upstream docs.
>>>>> I hope you work with the neutron team and run the third party
>>>>> requirements.
>>>>>
>>>>> Thanks,
>>>>> Akihiro
>>>>>
>>>>> On Tue, Oct 14, 2014 at 10:09 AM, Kyle Mestery <mestery at mestery.com>
>>>>> wrote:
>>>>> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton <blak111 at gmail.com>
>>>>> wrote:
>>>>> >>>The OpenStack dev and docs team dont have to worry about
>>>>> >>> gating/publishing/maintaining the vendor specific plugins/drivers.
>>>>> >>
>>>>> >> I disagree about the gating part. If a vendor wants to have a link
>>>>> that
>>>>> >> shows they are compatible with openstack, they should be reporting
>>>>> test
>>>>> >> results on all patches. A link to a vendor driver in the docs
>>>>> should signify
>>>>> >> some form of testing that the community is comfortable with.
>>>>> >>
>>>>> > I agree with Kevin here. If you want to play upstream, in whatever
>>>>> > form that takes by the end of Kilo, you have to work with the
>>>>> existing
>>>>> > third-party requirements and team to take advantage of being a part
>>>>> of
>>>>> > things like upstream docs.
>>>>> >
>>>>> > Thanks,
>>>>> > Kyle
>>>>> >
>>>>> >> On Mon, Oct 13, 2014 at 11:33 AM, Vadivel Poonathan
>>>>> >> <vadivel.openstack at gmail.com> wrote:
>>>>> >>>
>>>>> >>> Hi,
>>>>> >>>
>>>>> >>> If the plan is to move ALL existing vendor specific plugins/drivers
>>>>> >>> out-of-tree, then having a place-holder within the OpenStack
>>>>> domain would
>>>>> >>> suffice, where the vendors can list their plugins/drivers along
>>>>> with their
>>>>> >>> documentation as how to install and use etc.
>>>>> >>>
>>>>> >>> The main Openstack Neutron documentation page can explain the
>>>>> plugin
>>>>> >>> framework (ml2 type drivers, mechanism drivers, serviec plugin and
>>>>> so on)
>>>>> >>> and its purpose/usage etc, then provide a link to refer the
>>>>> currently
>>>>> >>> supported vendor specific plugins/drivers for more details.  That
>>>>> way the
>>>>> >>> documentation will be accurate to what is "in-tree" and limit the
>>>>> >>> documentation of external plugins/drivers to have just a reference
>>>>> link. So
>>>>> >>> its now vendor's responsibility to keep their  driver's up-to-date
>>>>> and their
>>>>> >>> documentation accurate. The OpenStack dev and docs team dont have
>>>>> to worry
>>>>> >>> about gating/publishing/maintaining the vendor specific
>>>>> plugins/drivers.
>>>>> >>>
>>>>> >>> The built-in drivers such as LinuxBridge or OpenVSwitch etc can
>>>>> continue
>>>>> >>> to be "in-tree" and their documentation will be part of main
>>>>> Neutron's docs.
>>>>> >>> So the Neutron is guaranteed to work with built-in plugins/drivers
>>>>> as per
>>>>> >>> the documentation and the user is informed to refer the "external
>>>>> vendor
>>>>> >>> plug-in page" for additional/specific plugins/drivers.
>>>>> >>>
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>> Vad
>>>>> >>> --
>>>>> >>>
>>>>> >>>
>>>>> >>> On Fri, Oct 10, 2014 at 8:10 PM, Anne Gentle <anne at openstack.org>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <blak111 at gmail.com>
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> I think you will probably have to wait until after the summit so
>>>>> we can
>>>>> >>>>> see the direction that will be taken with the rest of the in-tree
>>>>> >>>>> drivers/plugins. It seems like we are moving towards removing
>>>>> all of them so
>>>>> >>>>> we would definitely need a solution to documenting out-of-tree
>>>>> drivers as
>>>>> >>>>> you suggested.
>>>>> >>>>>
>>>>> >>>>> However, I think the minimum requirements for having a driver
>>>>> being
>>>>> >>>>> documented should be third-party testing of Neutron patches.
>>>>> Otherwise the
>>>>> >>>>> docs will become littered with a bunch of links to
>>>>> drivers/plugins with no
>>>>> >>>>> indication of what actually works, which ultimately makes
>>>>> Neutron look bad.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> This is my line of thinking as well, expanded to "ultimately makes
>>>>> >>>> OpenStack docs look bad" -- a perception I want to avoid.
>>>>> >>>>
>>>>> >>>> Keep the viewpoints coming. We have a crucial balancing act
>>>>> ahead: users
>>>>> >>>> need to trust docs and trust the drivers. Ultimately the
>>>>> responsibility for
>>>>> >>>> the docs is in the hands of the driver contributors so it seems
>>>>> those should
>>>>> >>>> be on a domain name where drivers control publishing and
>>>>> OpenStack docs are
>>>>> >>>> not a gatekeeper, quality checker, reviewer, or publisher.
>>>>> >>>>
>>>>> >>>> We have documented the status of hypervisor drivers on an
>>>>> OpenStack wiki
>>>>> >>>> page. [1] To me, that type of list could be maintained on the
>>>>> wiki page
>>>>> >>>> better than in the docs themselves. Thoughts? Feelings? More
>>>>> discussion,
>>>>> >>>> please. And thank you for the responses so far.
>>>>> >>>> Anne
>>>>> >>>>
>>>>> >>>> [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix
>>>>> >>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan
>>>>> >>>>> <vadivel.openstack at gmail.com> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Hi Anne,
>>>>> >>>>>>
>>>>> >>>>>> Thanks for your immediate response!...
>>>>> >>>>>>
>>>>> >>>>>> Just to clarify... I have developed and maintaining a Neutron
>>>>> plug-in
>>>>> >>>>>> (ML2 mechanism_driver) since Grizzly and now it is up-to-date
>>>>> with Icehouse.
>>>>> >>>>>> But it was never listed nor part of the main Openstack
>>>>> releases. Now i would
>>>>> >>>>>> like to have my plugin mentioned as "supported
>>>>> plugin/mechanism_driver for
>>>>> >>>>>> so and so vendor equipments" in the docs.openstack.org, but
>>>>> without having
>>>>> >>>>>> the actual plugin code to be posted in the main Openstack GIT
>>>>> repository.
>>>>> >>>>>>
>>>>> >>>>>> Reason is that I dont have plan/bandwidth to go thru the entire
>>>>> process
>>>>> >>>>>> of new plugin blue-print/development/review/testing etc as
>>>>> required by the
>>>>> >>>>>> Openstack development community. Bcos this is already
>>>>> developed, tested and
>>>>> >>>>>> released to some customers directly. Now I just want to get it
>>>>> to the
>>>>> >>>>>> official Openstack documentation, so that more people can get
>>>>> this and use.
>>>>> >>>>>>
>>>>> >>>>>> The plugin package is made available to public from Ubuntu
>>>>> repository
>>>>> >>>>>> along with necessary documentation. So people can directly get
>>>>> it from
>>>>> >>>>>> Ubuntu repository and use it. All i need is to get listed in the
>>>>> >>>>>> docs.openstack.org so that people knows that it exists and can
>>>>> be used with
>>>>> >>>>>> any Openstack.
>>>>> >>>>>>
>>>>> >>>>>> Pls. confrim whether this is something possible?...
>>>>> >>>>>>
>>>>> >>>>>> Thanks again!..
>>>>> >>>>>>
>>>>> >>>>>> Vad
>>>>> >>>>>> --
>>>>> >>>>>>
>>>>> >>>>>> On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle <
>>>>> anne at openstack.org>
>>>>> >>>>>> wrote:
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan
>>>>> >>>>>>> <vadivel.openstack at gmail.com> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> Hi,
>>>>> >>>>>>>>
>>>>> >>>>>>>> How to include a new vendor plug-in (aka mechanism_driver in
>>>>> ML2
>>>>> >>>>>>>> framework) into the Openstack documentation?.. In other
>>>>> words, is it
>>>>> >>>>>>>> possible to include a new plug-in in the Openstack
>>>>> documentation page
>>>>> >>>>>>>> without having the actual plug-in code as part of the
>>>>> Openstack neutron
>>>>> >>>>>>>> repository?... The actual plug-in is posted and available for
>>>>> the public to
>>>>> >>>>>>>> download as Ubuntu package. But i need to mention somewhere
>>>>> in the Openstack
>>>>> >>>>>>>> documentation that this new plugin is available for the
>>>>> public to use along
>>>>> >>>>>>>> with its documentation.
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> We definitely want you to include pointers to vendor
>>>>> documentation in
>>>>> >>>>>>> the OpenStack docs, but I'd prefer make sure they're gate
>>>>> tested before they
>>>>> >>>>>>> get listed on docs.openstack.org. Drivers change enough
>>>>> release-to-release
>>>>> >>>>>>> that it's difficult to keep up maintenance.
>>>>> >>>>>>>
>>>>> >>>>>>> Lately I've been talking to driver contributors (hypervisor,
>>>>> storage,
>>>>> >>>>>>> networking) about the out-of-tree changes possible. I'd like
>>>>> to encourage
>>>>> >>>>>>> even out-of-tree drivers to get listed, but to store their
>>>>> main documents
>>>>> >>>>>>> outside of docs.openstack.org, if they are gate-tested.
>>>>> >>>>>>>
>>>>> >>>>>>> Anyone have other ideas here?
>>>>> >>>>>>>
>>>>> >>>>>>> Looping in the OpenStack-docs mailing list also.
>>>>> >>>>>>> Anne
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> Pls. provide some insights into whether it is possible?.. and
>>>>> any
>>>>> >>>>>>>> further info on this?..
>>>>> >>>>>>>>
>>>>> >>>>>>>> Thanks,
>>>>> >>>>>>>>
>>>>> >>>>>>>> Vad
>>>>> >>>>>>>>
>>>>> >>>>>>>> --
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> _______________________________________________
>>>>> >>>>>>>> OpenStack-dev mailing list
>>>>> >>>>>>>> OpenStack-dev at lists.openstack.org
>>>>> >>>>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >>>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> _______________________________________________
>>>>> >>>>>>> OpenStack-dev mailing list
>>>>> >>>>>>> OpenStack-dev at lists.openstack.org
>>>>> >>>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> _______________________________________________
>>>>> >>>>>> OpenStack-dev mailing list
>>>>> >>>>>> OpenStack-dev at lists.openstack.org
>>>>> >>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> --
>>>>> >>>>> Kevin Benton
>>>>> >>>>>
>>>>> >>>>> _______________________________________________
>>>>> >>>>> OpenStack-dev mailing list
>>>>> >>>>> OpenStack-dev at lists.openstack.org
>>>>> >>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> OpenStack-dev mailing list
>>>>> >>>> OpenStack-dev at lists.openstack.org
>>>>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>> _______________________________________________
>>>>> >>> OpenStack-dev mailing list
>>>>> >>> OpenStack-dev at lists.openstack.org
>>>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Kevin Benton
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> OpenStack-dev mailing list
>>>>> >> OpenStack-dev at lists.openstack.org
>>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >>
>>>>> >
>>>>> > _______________________________________________
>>>>> > OpenStack-dev mailing list
>>>>> > OpenStack-dev at lists.openstack.org
>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Akihiro Motoki <amotoki at gmail.com>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/3137f16b/attachment.html>


More information about the OpenStack-dev mailing list