Open Stack

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?...

2) Who is the authority to clarify and confirm the above (and how do i
contact them)?...

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