Open Stack

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>