Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
; > >>> You haven't misunderstood anything, we're in the process of splitting >>> these things out, and this will be a prime focus of the Neutron design >>> summit track at the upcoming summit. >>> >>> Thanks, >>> Kyle >>> >>> > At the same time, IMHO, there must be some reference or a page within >>> the >>> > scope of OpenStack documentation (not necessarily the core docs, but >>> some >>> > wiki page or reference link or so - as Anne suggested) to mention the >>> list >>> > of the drivers/plugins supported as of given release and may be an >>> external >>> > link to know more details about the driver, if the link is provided by >>> > respective vendor. >>> > >>> > >>> > Anyway, besides my opinion, the wiki page similar to hypervisor driver >>> would >>> > be good for now atleast, until the direction/policy level decision is >>> made >>> > to maintain out-of-tree plugins/drivers. >>> > >>> > >>> > Thanks, >>> > Vad >>> > -- >>> > >>> > >>> > >>> > >>> > On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana < >>> edgar.mag...@workday.com> >>> > wrote: >>> >> >>> >> I second Anne’s and Kyle comments. Actually, I like very much the wiki >>> >> part to provide some visibility for out-of-tree plugins/drivers but >>> not into >>> >> the official documentation. >>> >> >>> >> Thanks, >>> >> >>> >> Edgar >>> >> >>> >> From: Anne Gentle >>> >> Reply-To: "OpenStack Development Mailing List (not for usage >>> questions)" >>> >> >>> >> Date: Thursday, October 23, 2014 at 8:51 AM >>> >> To: Kyle Mestery >>> >> Cc: "OpenStack Development Mailing List (not for usage questions)" >>> >> >>> >> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update >>> >> about new vendor plugin, but without code in repository? >>> >> >>> >> >>> >> >>> >> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery >>> >> 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 >>> >>> 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, >&
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
For anyone who had an interest in following this thread, they might want to have a look at [1], and [2] (which is the tl;dr version [1]). HTH Armando [1] https://review.openstack.org/#/c/134680 [2] http://lists.openstack.org/pipermail/openstack-dev/2014-December/052346.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/12/14 16:59, Vadivel Poonathan wrote: > Hi Kyle and all, > > Was there any conclusion in the design summit or the meetings > afterward about splitting the vendor plugins/drivers from the > mainstream neutron and documentation of out-of-tree > plugins/drivers?... It's expected that the following spec that covers the plugins split to be approved and implemented during Kilo: https://review.openstack.org/134680 > > Thanks, Vad -- > > > On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery > mailto:mest...@mestery.com>> wrote: > > On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan > mailto:vadivel.openst...@gmail.com>> > wrote: >> Hi Kyle and Anne, >> >> Thanks for the clarifications... understood and it makes sense. >> >> However, per my understanding, the drivers (aka plugins) are >> meant to be developed and supported by third-party vendors, >> outside of the OpenStack community, and they are supposed to work >> as plug-n-play... they are not part of the core OpenStack >> development, nor any of its components. If that is the case, then >> why should OpenStack community include and maintain them as part >> of it, for every release?... Wouldnt it be enough to limit the >> scope with the plugin framework and built-in drivers such as >> LinuxBridge or OVS etc?... not extending to commercial >> vendors?... (It is just a curious question, forgive me if i >> missed something and correct me!). >> > You haven't misunderstood anything, we're in the process of > splitting these things out, and this will be a prime focus of the > Neutron design summit track at the upcoming summit. > > Thanks, Kyle > >> At the same time, IMHO, there must be some reference or a page > within the >> scope of OpenStack documentation (not necessarily the core docs, > but some >> wiki page or reference link or so - as Anne suggested) to >> mention > the list >> of the drivers/plugins supported as of given release and may be >> an > external >> link to know more details about the driver, if the link is >> provided by respective vendor. >> >> >> Anyway, besides my opinion, the wiki page similar to hypervisor > driver would >> be good for now atleast, until the direction/policy level >> decision > is made >> to maintain out-of-tree plugins/drivers. >> >> >> Thanks, Vad -- >> >> >> >> >> On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana > mailto:edgar.mag...@workday.com>> >> wrote: >>> >>> I second Anne’s and Kyle comments. Actually, I like very much >>> the > wiki >>> part to provide some visibility for out-of-tree >>> plugins/drivers > but not into >>> the official documentation. >>> >>> Thanks, >>> >>> Edgar >>> >>> From: Anne Gentle >> <mailto:a...@openstack.org>> Reply-To: "OpenStack Development >>> Mailing List (not for usage > questions)" >>> <mailto:openstack-dev@lists.openstack.org>> >>> Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery >>> mailto:mest...@mestery.com>> Cc: >>> "OpenStack Development Mailing List (not for usage questions)" >>> <mailto:openstack-dev@lists.openstack.org>> >>> Subject: Re: [openstack-dev] [Neutron] Neutron documentation >>> to > update >>> about new vendor plugin, but without code in repository? >>> >>> >>> >>> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery > mailto: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 oth
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
Hi Vadivel, We do have a blueprint in the docs-specs repo under review for driver documentation and I'd like to get your input. https://review.openstack.org/#/c/133372/ Here's a relevant excerpt: The documentation team will fully document the reference drivers as specified below and just add short sections for other drivers. Guidelines for drivers that will be documented fully in the OpenStack documentation: * The complete solution must be open source and use standard hardware * The driver must be part of the respective OpenStack repository * The driver is considered one of the reference drivers For documentation of other drivers, the following guidelines apply: * The Configuration Reference will contain a small section for each driver, see below for details * Only drivers are covered that are contained in the official OpenStack project repository for drivers (for example in the main project repository or the official "third party" repository). With this policy, the docs team will document in their guides the following: * For cinder: volume drivers: document LVM only (TBD later: Samba, glusterfs); backup drivers: document swift (TBD later: ceph) * For glance: Document local storage, cinder, and swift as backends * For neutron: document ML2 plug-in with the mechanisms drivers OpenVSwitch and LinuxBridge * For nova: document KVM (mostly), send Xen open source call for help * For sahara: apache hadoop * For trove: document all supported Open Source database engines like MySQL. Let us know in the review itself if this answers your question about third-party drivers not in an official repository. Thanks, Anne On Thu, Dec 4, 2014 at 9:59 AM, Vadivel Poonathan < vadivel.openst...@gmail.com> wrote: > Hi Kyle and all, > > Was there any conclusion in the design summit or the meetings afterward > about splitting the vendor plugins/drivers from the mainstream neutron and > documentation of out-of-tree plugins/drivers?... > > Thanks, > Vad > -- > > > On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery > wrote: > >> On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan >> wrote: >> > Hi Kyle and Anne, >> > >> > Thanks for the clarifications... understood and it makes sense. >> > >> > However, per my understanding, the drivers (aka plugins) are meant to be >> > developed and supported by third-party vendors, outside of the OpenStack >> > community, and they are supposed to work as plug-n-play... they are not >> part >> > of the core OpenStack development, nor any of its components. If that >> is the >> > case, then why should OpenStack community include and maintain them as >> part >> > of it, for every release?... Wouldnt it be enough to limit the scope >> with >> > the plugin framework and built-in drivers such as LinuxBridge or OVS >> etc?... >> > not extending to commercial vendors?... (It is just a curious question, >> > forgive me if i missed something and correct me!). >> > >> You haven't misunderstood anything, we're in the process of splitting >> these things out, and this will be a prime focus of the Neutron design >> summit track at the upcoming summit. >> >> Thanks, >> Kyle >> >> > At the same time, IMHO, there must be some reference or a page within >> the >> > scope of OpenStack documentation (not necessarily the core docs, but >> some >> > wiki page or reference link or so - as Anne suggested) to mention the >> list >> > of the drivers/plugins supported as of given release and may be an >> external >> > link to know more details about the driver, if the link is provided by >> > respective vendor. >> > >> > >> > Anyway, besides my opinion, the wiki page similar to hypervisor driver >> would >> > be good for now atleast, until the direction/policy level decision is >> made >> > to maintain out-of-tree plugins/drivers. >> > >> > >> > Thanks, >> > Vad >> > -- >> > >> > >> > >> > >> > On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana > > >> > wrote: >> >> >> >> I second Anne’s and Kyle comments. Actually, I like very much the wiki >> >> part to provide some visibility for out-of-tree plugins/drivers but >> not into >> >> the official documentation. >> >> >> >> Thanks, >> >> >> >> Edgar >> >> >> >> From: Anne Gentle >> >> Reply-To: "OpenStack Development Mailing List (not for usage >> questions)" >> >> >
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
Hi Kyle and all, Was there any conclusion in the design summit or the meetings afterward about splitting the vendor plugins/drivers from the mainstream neutron and documentation of out-of-tree plugins/drivers?... Thanks, Vad -- On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery wrote: > On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan > wrote: > > Hi Kyle and Anne, > > > > Thanks for the clarifications... understood and it makes sense. > > > > However, per my understanding, the drivers (aka plugins) are meant to be > > developed and supported by third-party vendors, outside of the OpenStack > > community, and they are supposed to work as plug-n-play... they are not > part > > of the core OpenStack development, nor any of its components. If that is > the > > case, then why should OpenStack community include and maintain them as > part > > of it, for every release?... Wouldnt it be enough to limit the scope > with > > the plugin framework and built-in drivers such as LinuxBridge or OVS > etc?... > > not extending to commercial vendors?... (It is just a curious question, > > forgive me if i missed something and correct me!). > > > You haven't misunderstood anything, we're in the process of splitting > these things out, and this will be a prime focus of the Neutron design > summit track at the upcoming summit. > > Thanks, > Kyle > > > At the same time, IMHO, there must be some reference or a page within the > > scope of OpenStack documentation (not necessarily the core docs, but some > > wiki page or reference link or so - as Anne suggested) to mention the > list > > of the drivers/plugins supported as of given release and may be an > external > > link to know more details about the driver, if the link is provided by > > respective vendor. > > > > > > Anyway, besides my opinion, the wiki page similar to hypervisor driver > would > > be good for now atleast, until the direction/policy level decision is > made > > to maintain out-of-tree plugins/drivers. > > > > > > Thanks, > > Vad > > -- > > > > > > > > > > On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana > > wrote: > >> > >> I second Anne’s and Kyle comments. Actually, I like very much the wiki > >> part to provide some visibility for out-of-tree plugins/drivers but not > into > >> the official documentation. > >> > >> Thanks, > >> > >> Edgar > >> > >> From: Anne Gentle > >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" > >> > >> Date: Thursday, October 23, 2014 at 8:51 AM > >> To: Kyle Mestery > >> Cc: "OpenStack Development Mailing List (not for usage questions)" > >> > >> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update > >> about new vendor plugin, but without code in repository? > >> > >> > >> > >> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery > >> 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 > >>> wrote: > >>&
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
Edgar, Did we get consensus on having a wiki page for non-upstreamed drivers for Neutron?... or Are we waiting for summit outcome on the direction on how to handle the vendor plug-ins/drivers ? Thanks, Vad -- On Thu, Oct 23, 2014 at 12:07 PM, Vadivel Poonathan < vadivel.openst...@gmail.com> wrote: > > > On Thu, Oct 23, 2014 at 9:49 AM, Edgar Magana > wrote: > >> I forgot to mention that I can help to coordinate the creation and >> maintenance of the wiki for non-upstreamed drivers for Neutron. >> > >>[vad] Edgar, that would be nice!... but not sure whether it has to wait > till the outcome of the design discussion on this topic in the upcoming > summit??!... > > Thanks, > Vad > -- > > >> We need to be sure that we DO NOT confuse users with the current >> information here: >> https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers >> >> I have been maintaining that wiki and I would like to keep just for >> upstreamed vendor-specific plugins/drivers. >> >> Edgar >> >> From: Edgar Magana >> Date: Thursday, October 23, 2014 at 9:46 AM >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org>, Kyle Mestery >> >> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update >> about new vendor plugin, but without code in repository? >> >> I second Anne’s and Kyle comments. Actually, I like very much the wiki >> part to provide some visibility for out-of-tree plugins/drivers but not >> into the official documentation. >> >> Thanks, >> >> Edgar >> >> From: Anne Gentle >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> >> Date: Thursday, October 23, 2014 at 8:51 AM >> To: Kyle Mestery >> Cc: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update >> about new vendor plugin, but without code in repository? >> >> >> >> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery >> 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 >>> 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 >>> > 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 >>> wrote: >>> >>> >>> >>> >>&
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
On Thu, Oct 23, 2014 at 9:49 AM, Edgar Magana wrote: > I forgot to mention that I can help to coordinate the creation and > maintenance of the wiki for non-upstreamed drivers for Neutron. > >>[vad] Edgar, that would be nice!... but not sure whether it has to wait till the outcome of the design discussion on this topic in the upcoming summit??!... Thanks, Vad -- > We need to be sure that we DO NOT confuse users with the current > information here: > https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers > > I have been maintaining that wiki and I would like to keep just for > upstreamed vendor-specific plugins/drivers. > > Edgar > > From: Edgar Magana > Date: Thursday, October 23, 2014 at 9:46 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org>, Kyle Mestery > > Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update > about new vendor plugin, but without code in repository? > > I second Anne’s and Kyle comments. Actually, I like very much the wiki > part to provide some visibility for out-of-tree plugins/drivers but not > into the official documentation. > > Thanks, > > Edgar > > From: Anne Gentle > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Thursday, October 23, 2014 at 8:51 AM > To: Kyle Mestery > Cc: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update > about new vendor plugin, but without code in repository? > > > > On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery > 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 >> 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 >> > 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 >> wrote: >> >>> >> >>> >> >>> >> >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan >> >>> 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 >> >>
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan wrote: > Hi Kyle and Anne, > > Thanks for the clarifications... understood and it makes sense. > > However, per my understanding, the drivers (aka plugins) are meant to be > developed and supported by third-party vendors, outside of the OpenStack > community, and they are supposed to work as plug-n-play... they are not part > of the core OpenStack development, nor any of its components. If that is the > case, then why should OpenStack community include and maintain them as part > of it, for every release?... Wouldnt it be enough to limit the scope with > the plugin framework and built-in drivers such as LinuxBridge or OVS etc?... > not extending to commercial vendors?... (It is just a curious question, > forgive me if i missed something and correct me!). > You haven't misunderstood anything, we're in the process of splitting these things out, and this will be a prime focus of the Neutron design summit track at the upcoming summit. Thanks, Kyle > At the same time, IMHO, there must be some reference or a page within the > scope of OpenStack documentation (not necessarily the core docs, but some > wiki page or reference link or so - as Anne suggested) to mention the list > of the drivers/plugins supported as of given release and may be an external > link to know more details about the driver, if the link is provided by > respective vendor. > > > Anyway, besides my opinion, the wiki page similar to hypervisor driver would > be good for now atleast, until the direction/policy level decision is made > to maintain out-of-tree plugins/drivers. > > > Thanks, > Vad > -- > > > > > On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana > wrote: >> >> I second Anne’s and Kyle comments. Actually, I like very much the wiki >> part to provide some visibility for out-of-tree plugins/drivers but not into >> the official documentation. >> >> Thanks, >> >> Edgar >> >> From: Anne Gentle >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> >> Date: Thursday, October 23, 2014 at 8:51 AM >> To: Kyle Mestery >> Cc: "OpenStack Development Mailing List (not for usage questions)" >> >> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update >> about new vendor plugin, but without code in repository? >> >> >> >> On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery >> 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 >>> 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 >>> > 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
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
Hi Kyle and Anne, Thanks for the clarifications... understood and it makes sense. However, per my understanding, the drivers (aka plugins) are meant to be developed and supported by third-party vendors, outside of the OpenStack community, and they are supposed to work as plug-n-play... they are not part of the core OpenStack development, nor any of its components. If that is the case, then why should OpenStack community include and maintain them as part of it, for every release?... Wouldnt it be enough to limit the scope with the plugin framework and built-in drivers such as LinuxBridge or OVS etc?... not extending to commercial vendors?... (It is just a curious question, forgive me if i missed something and correct me!). At the same time, IMHO, there must be some reference or a page within the scope of OpenStack documentation (not necessarily the core docs, but some wiki page or reference link or so - as Anne suggested) to mention the list of the drivers/plugins supported as of given release and may be an external link to know more details about the driver, if the link is provided by respective vendor. Anyway, besides my opinion, the wiki page similar to hypervisor driver would be good for now atleast, until the direction/policy level decision is made to maintain out-of-tree plugins/drivers. Thanks, Vad -- On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana wrote: > I second Anne’s and Kyle comments. Actually, I like very much the wiki > part to provide some visibility for out-of-tree plugins/drivers but not > into the official documentation. > > Thanks, > > Edgar > > From: Anne Gentle > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Thursday, October 23, 2014 at 8:51 AM > To: Kyle Mestery > Cc: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update > about new vendor plugin, but without code in repository? > > > > On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery > 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 >> 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 >> > 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 >> wrote: >> >>> >> >>> >> >>> >> >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan >> >>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton < >> blak...@gmail.com> >> >>>> >>>> wrote: >> >>>> >>>>>
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
I forgot to mention that I can help to coordinate the creation and maintenance of the wiki for non-upstreamed drivers for Neutron. We need to be sure that we DO NOT confuse users with the current information here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers I have been maintaining that wiki and I would like to keep just for upstreamed vendor-specific plugins/drivers. Edgar From: Edgar Magana mailto:edgar.mag...@workday.com>> Date: Thursday, October 23, 2014 at 9:46 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>>, Kyle Mestery mailto:mest...@mestery.com>> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository? I second Anne’s and Kyle comments. Actually, I like very much the wiki part to provide some visibility for out-of-tree plugins/drivers but not into the official documentation. Thanks, Edgar From: Anne Gentle mailto:a...@openstack.org>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery mailto:mest...@mestery.com>> Cc: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository? On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery mailto: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 mailto: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 > mailto: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 >> mailto:a...@openstack.org>> wrote: >>> >>> >>> >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan >>> mailto:vadivel.openst...@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton >>>> >>>> mailto: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
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
I second Anne’s and Kyle comments. Actually, I like very much the wiki part to provide some visibility for out-of-tree plugins/drivers but not into the official documentation. Thanks, Edgar From: Anne Gentle mailto:a...@openstack.org>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery mailto:mest...@mestery.com>> Cc: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository? On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery mailto: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 mailto: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 > mailto: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 >> mailto:a...@openstack.org>> wrote: >>> >>> >>> >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan >>> mailto:vadivel.openst...@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton >>>> >>>> mailto: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
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery 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 > 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 > > 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 > wrote: > >>> > >>> > >>> > >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan > >>> wrote: > > Hi, > > On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton > > 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 > wrote: > > > > > > > > On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan > > 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 > > >> 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
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
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. Thanks, Kyle On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan 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 > 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 wrote: >>> >>> >>> >>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan >>> wrote: Hi, On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton 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 wrote: > > > > On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan > 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 >> 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 >>> wrote: >>> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton >>> > 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
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
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 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 >> > 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 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 > 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 >> wrote: >> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton >> 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 >> >> 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 woul
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
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 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 > > 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 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 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 > wrote: > > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton > 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 > >> 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 specif
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
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 > 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 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 >>> 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 wrote: > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton 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 >> 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/mai
Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?
Hi, * On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton > 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?... 2) Who is the authority to clarify and confirm the above (and how do i contact them)?... Thanks again for your inputs... Regards, Vad -- On Tue, Oct 14, 2014 at 3:17 PM, Anne Gentle 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 >> 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 >>> wrote: >>> > On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton >>> 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 >>> >> 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. >>> >>> >>> >>> >>> >>>
