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.
Thanks, Vad -- On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki <amot...@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 <mest...@mestery.com> > wrote: > > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton <blak...@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.openst...@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 <a...@openstack.org> > wrote: > >>>> > >>>> > >>>> > >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton <blak...@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.openst...@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 <a...@openstack.org> > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan > >>>>>>> <vadivel.openst...@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@lists.openstack.org > >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OpenStack-dev mailing list > >>>>>>> OpenStack-dev@lists.openstack.org > >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OpenStack-dev mailing list > >>>>>> OpenStack-dev@lists.openstack.org > >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Kevin Benton > >>>>> > >>>>> _______________________________________________ > >>>>> OpenStack-dev mailing list > >>>>> OpenStack-dev@lists.openstack.org > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OpenStack-dev mailing list > >>>> OpenStack-dev@lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>> > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> > >> -- > >> Kevin Benton > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Akihiro Motoki <amot...@gmail.com> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev