[openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

Vadivel Poonathan vadivel.openstack at gmail.com
Mon Oct 13 18:33:22 UTC 2014


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


More information about the OpenStack-dev mailing list