Open Stack

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