Open Stack

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