Open Stack

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
>>> <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/20141023/a3859a3f/attachment.html>