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

[Vadivel Poonathan]

Hi,

How to include a new vendor plug-in (aka mechanism_driver in ML2 framework)
into the Openstack documentation?.. In other words, is it possible to
include a new plug-in in the Openstack documentation page without having
the actual plug-in code as part of the Openstack neutron repository?... The
actual plug-in is posted and available for the public to download as Ubuntu
package. But i need to mention somewhere in the Openstack documentation
that this new plugin is available for the public to use along with its
documentation.

Pls. provide some insights into whether it is possible?.. and any further
info on this?..

Thanks,

Vad

--
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vadivel Poonathan]

Hi Anne,

Thanks for your immediate response!...

Just to clarify... I have developed and maintaining a Neutron plug-in (ML2
mechanism_driver) since Grizzly and now it is up-to-date with Icehouse. But
it was never listed nor part of the main Openstack releases. Now i would
like to have my plugin mentioned as supported plugin/mechanism_driver for
so and so vendor equipments in the docs.openstack.org, but without having
the actual plugin code to be posted in the main Openstack GIT repository.

Reason is that I dont have plan/bandwidth to go thru the entire process of
new plugin blue-print/development/review/testing etc as required by the
Openstack development community. Bcos this is already developed, tested and
released to some customers directly. Now I just want to get it to the
official Openstack documentation, so that more people can get this and use.

The plugin package is made available to public from Ubuntu repository along
with necessary documentation. So people can directly get it from Ubuntu
repository and use it. All i need is to get listed in the docs.openstack.org
so that people knows that it exists and can be used with any Openstack.

Pls. confrim whether this is something possible?...

Thanks again!..

Vad
--

On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle a...@openstack.org wrote:



 On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan 
 vadivel.openst...@gmail.com wrote:

 Hi,

 How to include a new vendor plug-in (aka mechanism_driver in ML2
 framework) into the Openstack documentation?.. In other words, is it
 possible to include a new plug-in in the Openstack documentation page
 without having the actual plug-in code as part of the Openstack neutron
 repository?... The actual plug-in is posted and available for the public to
 download as Ubuntu package. But i need to mention somewhere in the
 Openstack documentation that this new plugin is available for the public to
 use along with its documentation.


 We definitely want you to include pointers to vendor documentation in the
 OpenStack docs, but I'd prefer make sure they're gate tested before they
 get listed on docs.openstack.org. Drivers change enough
 release-to-release that it's difficult to keep up maintenance.

 Lately I've been talking to driver contributors (hypervisor, storage,
 networking) about the out-of-tree changes possible. I'd like to encourage
 even out-of-tree drivers to get listed, but to store their main documents
 outside of docs.openstack.org, if they are gate-tested.

 Anyone have other ideas here?

 Looping in the OpenStack-docs mailing list also.
 Anne



 Pls. provide some insights into whether it is possible?.. and any further
 info on this?..

 Thanks,

 Vad

 --

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vadivel Poonathan]

Hi,

If the plan is to move ALL existing vendor specific plugins/drivers
out-of-tree, then having a place-holder within the OpenStack domain would
suffice, where the vendors can list their plugins/drivers along with their
documentation as how to install and use etc.

The main Openstack Neutron documentation page can explain the plugin
framework (ml2 type drivers, mechanism drivers, serviec plugin and so on)
and its purpose/usage etc, then provide a link to refer the currently
supported vendor specific plugins/drivers for more details.  That way the
documentation will be accurate to what is in-tree and limit the
documentation of external plugins/drivers to have just a reference link. So
its now vendor's responsibility to keep their  driver's up-to-date and
their documentation accurate. The OpenStack dev and docs team dont have to
worry about gating/publishing/maintaining the vendor specific
plugins/drivers.

The built-in drivers such as LinuxBridge or OpenVSwitch etc can continue to
be in-tree and their documentation will be part of main Neutron's docs.
So the Neutron is guaranteed to work with built-in plugins/drivers as per
the documentation and the user is informed to refer the external vendor
plug-in page for additional/specific plugins/drivers.


Thanks,
Vad
--


On Fri, Oct 10, 2014 at 8:10 PM, Anne Gentle a...@openstack.org wrote:



 On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton blak...@gmail.com wrote:

 I think you will probably have to wait until after the summit so we can
 see the direction that will be taken with the rest of the in-tree
 drivers/plugins. It seems like we are moving towards removing all of them
 so we would definitely need a solution to documenting out-of-tree drivers
 as you suggested.

 However, I think the minimum requirements for having a driver being
 documented should be third-party testing of Neutron patches. Otherwise the
 docs will become littered with a bunch of links to drivers/plugins with no
 indication of what actually works, which ultimately makes Neutron look bad.


 This is my line of thinking as well, expanded to ultimately makes
 OpenStack docs look bad -- a perception I want to avoid.

 Keep the viewpoints coming. We have a crucial balancing act ahead: users
 need to trust docs and trust the drivers. Ultimately the responsibility for
 the docs is in the hands of the driver contributors so it seems those
 should be on a domain name where drivers control publishing and OpenStack
 docs are not a gatekeeper, quality checker, reviewer, or publisher.

 We have documented the status of hypervisor drivers on an OpenStack wiki
 page. [1] To me, that type of list could be maintained on the wiki page
 better than in the docs themselves. Thoughts? Feelings? More discussion,
 please. And thank you for the responses so far.
 Anne

 [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix



 On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan 
 vadivel.openst...@gmail.com wrote:

 Hi Anne,

 Thanks for your immediate response!...

 Just to clarify... I have developed and maintaining a Neutron plug-in
 (ML2 mechanism_driver) since Grizzly and now it is up-to-date with
 Icehouse. But it was never listed nor part of the main Openstack releases.
 Now i would like to have my plugin mentioned as supported
 plugin/mechanism_driver for so and so vendor equipments in the
 docs.openstack.org, but without having the actual plugin code to be
 posted in the main Openstack GIT repository.

 Reason is that I dont have plan/bandwidth to go thru the entire process
 of new plugin blue-print/development/review/testing etc as required by the
 Openstack development community. Bcos this is already developed, tested and
 released to some customers directly. Now I just want to get it to the
 official Openstack documentation, so that more people can get this and use.

 The plugin package is made available to public from Ubuntu repository
 along with necessary documentation. So people can directly get it from
 Ubuntu repository and use it. All i need is to get listed in the
 docs.openstack.org so that people knows that it exists and can be used
 with any Openstack.

 Pls. confrim whether this is something possible?...

 Thanks again!..

 Vad
 --

 On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle a...@openstack.org
 wrote:



 On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan 
 vadivel.openst...@gmail.com wrote:

 Hi,

 How to include a new vendor plug-in (aka mechanism_driver in ML2
 framework) into the Openstack documentation?.. In other words, is it
 possible to include a new plug-in in the Openstack documentation page
 without having the actual plug-in code as part of the Openstack neutron
 repository?... The actual plug-in is posted and available for the public 
 to
 download as Ubuntu package. But i need to mention somewhere in the
 Openstack documentation that this new plugin is available for the public 
 to
 use along with its documentation.


 We definitely want you to include pointers

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

[Vadivel Poonathan]

Agreed on the requirements of test results to qualify the vendor plugin to
be listed in the upstream docs.
Is there any procedure/infrastructure currently available for this
purpose?..
Pls. fwd any link/pointers on those info.

Thanks,
Vad
--

On Mon, Oct 13, 2014 at 10:25 PM, Akihiro Motoki amot...@gmail.com wrote:

 I agree with Kevin and Kyle. Even if we decided to use separate tree for
 neutron
 plugins and drivers, they still will be regarded as part of the upstream.
 These plugins/drivers need to prove they are well integrated with Neutron
 master
 in some way and gating integration proves it is well tested and integrated.
 I believe it is a reasonable assumption and requirement that a vendor
 plugin/driver
 is listed in the upstream docs. This is a same kind of question as
 what vendor plugins
 are tested and worth documented in the upstream docs.
 I hope you work with the neutron team and run the third party requirements.

 Thanks,
 Akihiro

 On Tue, Oct 14, 2014 at 10:09 AM, Kyle Mestery mest...@mestery.com
 wrote:
  On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton blak...@gmail.com wrote:
 The OpenStack dev and docs team dont have to worry about
  gating/publishing/maintaining the vendor specific plugins/drivers.
 
  I disagree about the gating part. If a vendor wants to have a link that
  shows they are compatible with openstack, they should be reporting test
  results on all patches. A link to a vendor driver in the docs should
 signify
  some form of testing that the community is comfortable with.
 
  I agree with Kevin here. If you want to play upstream, in whatever
  form that takes by the end of Kilo, you have to work with the existing
  third-party requirements and team to take advantage of being a part of
  things like upstream docs.
 
  Thanks,
  Kyle
 
  On Mon, Oct 13, 2014 at 11:33 AM, Vadivel Poonathan
  vadivel.openst...@gmail.com wrote:
 
  Hi,
 
  If the plan is to move ALL existing vendor specific plugins/drivers
  out-of-tree, then having a place-holder within the OpenStack domain
 would
  suffice, where the vendors can list their plugins/drivers along with
 their
  documentation as how to install and use etc.
 
  The main Openstack Neutron documentation page can explain the plugin
  framework (ml2 type drivers, mechanism drivers, serviec plugin and so
 on)
  and its purpose/usage etc, then provide a link to refer the currently
  supported vendor specific plugins/drivers for more details.  That way
 the
  documentation will be accurate to what is in-tree and limit the
  documentation of external plugins/drivers to have just a reference
 link. So
  its now vendor's responsibility to keep their  driver's up-to-date and
 their
  documentation accurate. The OpenStack dev and docs team dont have to
 worry
  about gating/publishing/maintaining the vendor specific
 plugins/drivers.
 
  The built-in drivers such as LinuxBridge or OpenVSwitch etc can
 continue
  to be in-tree and their documentation will be part of main Neutron's
 docs.
  So the Neutron is guaranteed to work with built-in plugins/drivers as
 per
  the documentation and the user is informed to refer the external
 vendor
  plug-in page for additional/specific plugins/drivers.
 
 
  Thanks,
  Vad
  --
 
 
  On Fri, Oct 10, 2014 at 8:10 PM, Anne Gentle a...@openstack.org
 wrote:
 
 
 
  On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton blak...@gmail.com
 wrote:
 
  I think you will probably have to wait until after the summit so we
 can
  see the direction that will be taken with the rest of the in-tree
  drivers/plugins. It seems like we are moving towards removing all of
 them so
  we would definitely need a solution to documenting out-of-tree
 drivers as
  you suggested.
 
  However, I think the minimum requirements for having a driver being
  documented should be third-party testing of Neutron patches.
 Otherwise the
  docs will become littered with a bunch of links to drivers/plugins
 with no
  indication of what actually works, which ultimately makes Neutron
 look bad.
 
 
  This is my line of thinking as well, expanded to ultimately makes
  OpenStack docs look bad -- a perception I want to avoid.
 
  Keep the viewpoints coming. We have a crucial balancing act ahead:
 users
  need to trust docs and trust the drivers. Ultimately the
 responsibility for
  the docs is in the hands of the driver contributors so it seems those
 should
  be on a domain name where drivers control publishing and OpenStack
 docs are
  not a gatekeeper, quality checker, reviewer, or publisher.
 
  We have documented the status of hypervisor drivers on an OpenStack
 wiki
  page. [1] To me, that type of list could be maintained on the wiki
 page
  better than in the docs themselves. Thoughts? Feelings? More
 discussion,
  please. And thank you for the responses so far.
  Anne
 
  [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix
 
 
 
  On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan
  vadivel.openst...@gmail.com wrote:
 
  Hi Anne

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

[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

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

[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

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

[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

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

[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

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

[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

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

[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

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

[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

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Vadivel Poonathan]

@Armando,

Okay, so if I understand you correctly, you're saying that was easier for
you to go entirely out of tree, and that you have done so already. Okay,
good for you, problem solved!

One point that should be clear here is that, if someone is completely
comfortable with being entirely out of tree, and he/she has done so already
(I know of a few other examples besides the apic driver), then this
proposal does not apply to them.

[vad] how about the documentation in this case?... bcos it needs some
place to document (a short desc and a link to vendor page) or list these
kind of out-of-tree plugins/drivers...  just to make the user aware of the
availability of such plugins/driers which is compatible with so and so
openstack release.

I checked with the documentation team and according to them, only the
following plugins/drivers only will get documented...
1) in-tree plugins/drivers (full documentation)
2) third-party plugins/drivers (ie, one implements and follows this new
proposal, a.k.a partially-in-tree due to the integration module/code)...

*** no listing/mention about such completely out-of-tree plugins/drivers***


In my case, i have a fully working/deployed out-of-tree plugin/mech_driver
(compatible with Havana, Icehouse and Juno releases), but i couldnt get it
listed or mentioned in the openstack plugin/driver documentation. Now only
way to get my (out-of-tree) driver documented is to make it
'partially-in-the-tree' driver by implementing this new proposal. Though
this is far better then earlier requirements/approval/maintenance overhead,
i got to implement this proposal just for documentation purpose.

Thanks,
Vad
-- 

On Tue, Dec 9, 2014 at 2:21 PM, Armando M. arma...@gmail.com wrote:



 On 9 December 2014 at 13:59, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 I agree with Salvatore that the split is not an easy thing to achieve for
 vendors, and I would like to bring up my case to see if there are ways to
 make this at least a bit simpler.

 At some point I had the need to backport vendor code from Juno to
 Icehouse (see first attempt here [0]). That in [0] was some weird approach
 that put unnecessary burden on infra, neutron cores and even packagers, so
 I decided to move to a more decoupled approach that was basically
 completely splitting my code from Neutron. You can find the result here [1].
 The focal points of this approach are:

 * **all** the vendor code is removed;
 * Neutron is used as a dependency, pulled directly from github for UTs
 (see test-requirements [2]) and explicitly required when installing the
 plugin;
 * The Database and Schema is the same as Neutron's;
 * A migration script exists for this driver, which uses a different (and
 unique) version_table (see env.py [3]);
 * Entry points are properly used in setup.cfg [4] in order to provide
 migration scripts and Driver/Plugin shortcuts for Neutron;
 * UTs are run by including Neutron in the venv [2].
 * The boilerplate is taken care by cookiecutter [5].


 The advantage of the above approach, is that it's very simple to pull off
 (only thing you need is cookiecutter, a repo, and then you can just
 replicate the same tree structure that existed in Neutron for your own
 vendor code). Also it has the advantage to remove all the vendor code from
 Neutron (did I say that already?). As far as the CI is concerned, it just
 needs to learn how to install the new plugin, which will require Neutron
 to be pre-existent.

 The typical installation workflow would be:
 - Install Neutron normally;
 - pull from pypi the vendor driver;
 - run the vendor db migration script;
 - Do everything else (configuration and execution) just like it was done
 before.

 Note that this same satellite approach is used by GBP (I know this is a
 bad word that once brought hundreds of ML replies, but that's just an
 example :) ) for the Juno timeframe [6]. This shows that the very same
 thing can be easily done for services.


 Okay, so if I understand you correctly, you're saying that was easier for
 you to go entirely out of tree, and that you have done so already. Okay,
 good for you, problem solved!

 One point that should be clear here is that, if someone is completely
 comfortable with being entirely out of tree, and he/she has done so already
 (I know of a few other examples besides the apic driver), then this
 proposal does not apply to them.

 They are way ahead of us, and kudos to them!

 As far you're concerned, Ivar, if you want to promote this model for new
 plugins/drivers contributions, by all means, I encourage you to document
 this in a blog or the wiki and disseminate your findings so that people can
 adopt your model if they wanted to.



 As far as ML2 is concerned, I think we should split it as well in order
 to treat all the plugins equally, but with the following caveats:

 * ML2 will be in a openstack repo under the networking program (kind of
 obvious);
 * The drivers can decide wether to stay in tree with ML2 or not (for a
 

[openstack-dev] Neutron sub-project release association with Liberty?

[Vadivel Poonathan]

Hi,

Once the Neutron's sub-project is released to pyPI, where does it show that
this sub-project release is associated with Liberty release of Openstack?..
I tried to see it in the Liberty Release notes, but it doesn't have any
info about the supported/released vendor plug-ins/drivers.

I see the plug-in is listed here in the official sub-project list, but
again it is not specific to a particular release.
http://docs.openstack.org/developer/neutron/devref/sub_projects.html



In the following link, i see but only some vendor plug-ins, not all is
listed here!... why only some of vendor drivers are shipped with Openstack
and not all?..
https://www.openstack.org/marketplace/drivers/


So what is the criteria to get a vendor plug-in listed on this page? or
where can i see the supported vendor plugins/drivers for a given Openstack
release (specfically Liberty) ??

Any info/link on this would be much helpful and appreciated?...

Thanks,
Vad
--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] adding new vendor driver to upstream

[Vadivel Poonathan]

Hi Armando,

Thanks for the pointer. I will go thru the same and get back to you/group,
in case of any clarification.

Here is the outdated wiki pages that i came across... these may have to be
updated/cleaned-up to reflect the recent changes about
development/contribution of new vendor plugins/drivers...
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
https://wiki.openstack.org/wiki/NeutronDevelopment
https://wiki.openstack.org/wiki/Neutron

Thanks,
Vad
--


On Fri, Jul 10, 2015 at 4:54 PM, Armando M. arma...@gmail.com wrote:


 On 10 July 2015 at 16:01, Vadivel Poonathan vadivel.openst...@gmail.com
 wrote:

 Hi,

 I have a Neutron plugin (actually a mechanism_driver under ML2) developed
 for Alcatel-Lucent Omniswitches and is currently being used. But it is not
 part of Neutron upstream, nor listed in the docs/wiki section. I tried to
 make it part of Kilo release, but that was when the decomposition proposal
 was going on. Infact i reviewed the blueprint spec and provided some
 comments too. Since i had to decompose my driver as per the Kilo's
 decomposition spec, i deferred it to make it as part of Liberty release.

 Now going thru some wiki pages, blueprint specs etc, i 'm not clear on
 the procedures/criteria to make my driver integrated with upstream
 Neutron.  Its all scattered and some says all vendor code is moved
 out-of-tree in Liberty, some says only vendor library is moved, some says
 third-party CI system is no longer required, some says it is one of the key
 requirement.


 This is the most up-to-date place to look for to get you started:


 https://github.com/openstack/neutron/blob/master/doc/source/devref/contribute.rst

 There is no wiki afaik, and only one spec that targeted the Kilo release,
 so I I'd be curious to know what you mean by 'it's all scattered', as I'd
 love to clean this up if possible.



 *So i appreciate if someone could get me the exact step-by-step
  procedure (the most recent, applicable to Liberty release) to have my
 driver released as part of Liberty and its documentation. *


 If you still have questions, feel free to reach us out on
 #openstack-neutron.

 A.




 Here is my objective...
 1) make my mechanism driver pkg available in the Neutron repository,
 accessible by public
 2) update my mechanism driver in the list of supported vendor
 plugin/driver page, along with some documentation

 Pls. advise.

 Thanks and Regards,
 Vad
 --

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] adding new vendor driver to upstream

[Vadivel Poonathan]

Hi,

I have a Neutron plugin (actually a mechanism_driver under ML2) developed
for Alcatel-Lucent Omniswitches and is currently being used. But it is not
part of Neutron upstream, nor listed in the docs/wiki section. I tried to
make it part of Kilo release, but that was when the decomposition proposal
was going on. Infact i reviewed the blueprint spec and provided some
comments too. Since i had to decompose my driver as per the Kilo's
decomposition spec, i deferred it to make it as part of Liberty release.

Now going thru some wiki pages, blueprint specs etc, i 'm not clear on the
procedures/criteria to make my driver integrated with upstream Neutron.
Its all scattered and some says all vendor code is moved out-of-tree in
Liberty, some says only vendor library is moved, some says third-party CI
system is no longer required, some says it is one of the key requirement.

*So i appreciate if someone could get me the exact step-by-step  procedure
(the most recent, applicable to Liberty release) to have my driver released
as part of Liberty and its documentation. *


Here is my objective...
1) make my mechanism driver pkg available in the Neutron repository,
accessible by public
2) update my mechanism driver in the list of supported vendor plugin/driver
page, along with some documentation

Pls. advise.

Thanks and Regards,
Vad
--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Release of a neutron sub-project

[Vadivel Poonathan]

Kyle,

We referenced arista's setup/config files when we setup the pypi for
our plugin. So if it is ok for Arista, then it would be ok for
ale-omniswitch too, i believe. You said Arista was ok when you did in
google, instead of pypi search, in another email. So can you pls.
check again ale-omniswitch as well and confirm.

If still it has an issue, can you pls. throw me some pointers on where
to enable the openstackci owener permission?..

Thanks,Vad--

The following pypi registrations did not follow directions to enable
openstackci has "Owner" permissions, which allow for the publishing of

packages to pypi:

networking-ale-omniswitch
networking-arista


On Wed, Sep 30, 2015 at 11:56 AM, Kyle Mestery <mest...@mestery.com> wrote:

> On Tue, Sep 29, 2015 at 8:04 PM, Kyle Mestery <mest...@mestery.com> wrote:
>
>> On Tue, Sep 29, 2015 at 2:36 PM, Vadivel Poonathan <
>> vadivel.openst...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> As per the Sub-Project Release process - i would like to tag and release
>>> the following sub-project as part of upcoming Liberty release.
>>> The process says talk to one of the member of 'neutron-release' group. I
>>> couldn’t find a group mail-id for this group. Hence I am sending this email
>>> to the dev list.
>>>
>>> I just have removed the version from setup.cfg and got the patch merged,
>>> as specified in the release process. Can someone from the neutron-release
>>> group makes this sub-project release.
>>>
>>>
>>
>> Vlad, I'll do this tomorrow. Find me on IRC (mestery) and ping me there
>> so I can get your IRC NIC in case I have questions.
>>
>>
> It turns out that the networking-ale-omniswitch pypi setup isn't correct,
> see [1] for more info and how to correct. This turned out to be ok, because
> it's forced me to re-examine the other networking sub-projects and their
> pypi setup to ensure consistency, which the thread found here [1] will
> resolve.
>
> Once you resolve this ping me on IRC and I'll release this for you.
>
> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075880.html
>
>
>> Thanks!
>> Kyle
>>
>>
>>>
>>> ALE Omniswitch
>>> Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
>>> Launchpad: https://launchpad.net/networking-ale-omniswitch
>>> Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch
>>>
>>> Thanks,
>>> Vad
>>> --
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Release of a neutron sub-project

[Vadivel Poonathan]

Hi,

As per the Sub-Project Release process - i would like to tag and release
the following sub-project as part of upcoming Liberty release.
The process says talk to one of the member of 'neutron-release' group. I
couldn’t find a group mail-id for this group. Hence I am sending this email
to the dev list.

I just have removed the version from setup.cfg and got the patch merged, as
specified in the release process. Can someone from the neutron-release
group makes this sub-project release.


ALE Omniswitch
Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
Launchpad: https://launchpad.net/networking-ale-omniswitch
Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch

Thanks,
Vad
--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev