On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery <mest...@mestery.com> wrote:
> Vad: > > The third-party CI is required for your upstream driver. I think > what's different from my reading of this thread is the question of > what is the requirement to have a driver listed in the upstream > documentation which is not in the upstream codebase. To my knowledge, > we haven't done this. Thus, IMHO, we should NOT be utilizing upstream > documentation to document drivers which are themselves not upstream. > When we split out the drivers which are currently upstream in neutron > into a separate repo, they will still be upstream. So my opinion here > is that if your driver is not upstream, it shouldn't be in the > upstream documentation. But I'd like to hear others opinions as well. > > This is my sense as well. The hypervisor drivers are documented on the wiki, sometimes they're in-tree, sometimes they're not, but the state of testing is documented on the wiki. I think we could take this approach for network and storage drivers as well. https://wiki.openstack.org/wiki/HypervisorSupportMatrix Anne > Thanks, > Kyle > > On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan > <vadivel.openst...@gmail.com> wrote: > > Kyle, > > Gentle reminder... when you get a chance!.. > > > > Anne, > > In case, if i need to send it to different group or email-id to reach > Kyle > > Mestery, pls. let me know. Thanks for your help. > > > > Regards, > > Vad > > -- > > > > > > On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan > > <vadivel.openst...@gmail.com> wrote: > >> > >> Hi Kyle, > >> > >> Can you pls. comment on this discussion and confirm the requirements for > >> getting out-of-tree mechanism_driver listed in the supported > plugin/driver > >> list of the Openstack Neutron docs. > >> > >> Thanks, > >> Vad > >> -- > >> > >> On Mon, Oct 20, 2014 at 12:48 PM, Anne Gentle <a...@openstack.org> > wrote: > >>> > >>> > >>> > >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan > >>> <vadivel.openst...@gmail.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> >>>> 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. > >>>> > >>>> [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?... > >>>> > >>> > >>> The neutron PTL Kyle Mestery can answer if there are any additional > >>> requirements. > >>> > >>>> > >>>> 2) Who is the authority to clarify and confirm the above (and how do i > >>>> contact them)?... > >>> > >>> > >>> Elections just completed, and the newly elected PTL is Kyle Mestery, > >>> > http://lists.openstack.org/pipermail/openstack-dev/2014-March/031433.html. > >>> > >>>> > >>>> > >>>> Thanks again for your inputs... > >>>> > >>>> Regards, > >>>> Vad > >>>> -- > >>>> > >>>> On Tue, Oct 14, 2014 at 3:17 PM, Anne Gentle <a...@openstack.org> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan > >>>>> <vadivel.openst...@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 <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 > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >> > > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
