Open Stack

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

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