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

2014-12-05 Thread Ihar Hrachyshka
-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
 mest...@mestery.com mailto:mest...@mestery.com wrote:
 
 On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan 
 vadivel.openst...@gmail.com 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
 edgar.mag...@workday.com 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 a...@openstack.org
 mailto:a...@openstack.org Reply-To: OpenStack Development
 Mailing List (not for usage
 questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery
 mest...@mestery.com mailto:mest...@mestery.com Cc:
 OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 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
 mest...@mestery.com 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 
 vadivel.openst...@gmail.com
 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 
 vadivel.openst...@gmail.com
 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
 

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

2014-12-05 Thread Armando M.
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?

2014-12-04 Thread Vadivel Poonathan
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 mest...@mestery.com wrote:

 On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan
 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 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 a...@openstack.org
  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 mest...@mestery.com
  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 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 

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

2014-11-10 Thread Vadivel Poonathan
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 edgar.mag...@workday.com
 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 edgar.mag...@workday.com
 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 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 a...@openstack.org
 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 mest...@mestery.com
 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 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 

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

2014-10-23 Thread Vadivel Poonathan
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
 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 

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

2014-10-23 Thread Kyle Mestery
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
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
 
 

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

2014-10-23 Thread Anne Gentle
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.
  

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

2014-10-23 Thread Edgar Magana
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 a...@openstack.orgmailto:a...@openstack.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 23, 2014 at 8:51 AM
To: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto: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 
mest...@mestery.commailto: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.commailto: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.commailto: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.orgmailto:a...@openstack.org wrote:



 On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan
 vadivel.openst...@gmail.commailto:vadivel.openst...@gmail.com wrote:

 Hi,

  On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton 
  blak...@gmail.commailto: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.orgmailto:a...@openstack.org wrote:



 On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan
 vadivel.openst...@gmail.commailto: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.commailto:amot...@gmail.com
 wrote:

 I agree with Kevin and Kyle. Even if we 

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

2014-10-23 Thread Edgar Magana
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 edgar.mag...@workday.commailto:edgar.mag...@workday.com
Date: Thursday, October 23, 2014 at 9:46 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Kyle Mestery mest...@mestery.commailto: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 a...@openstack.orgmailto:a...@openstack.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 23, 2014 at 8:51 AM
To: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto: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 
mest...@mestery.commailto: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.commailto: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.commailto: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.orgmailto:a...@openstack.org wrote:



 On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan
 vadivel.openst...@gmail.commailto:vadivel.openst...@gmail.com wrote:

 Hi,

  On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton 
  blak...@gmail.commailto: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 

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

2014-10-23 Thread Vadivel Poonathan
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 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 a...@openstack.org
 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 mest...@mestery.com
 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 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 

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

2014-10-23 Thread Vadivel Poonathan
On Thu, Oct 23, 2014 at 9:49 AM, Edgar Magana edgar.mag...@workday.com
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 edgar.mag...@workday.com
 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 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 a...@openstack.org
 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 mest...@mestery.com
 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 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 

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

2014-10-21 Thread Vadivel Poonathan
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
 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 

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

2014-10-20 Thread Vadivel Poonathan
Hi,







* On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton blak...@gmail.com
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?...

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

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

2014-10-20 Thread Anne Gentle
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
 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