From eca0d1ff24db10dc3ba54602ac5d9d271eff0a52 Mon Sep 17 00:00:00 2001 From: armando-migliaccio Date: Fri, 6 Feb 2015 23:44:07 -0800 Subject: [PATCH] Fix minor nits with the devref's contribute section Be more explicit on the adoption of Externally Hosted Plugins, which are based on Extra.d Hooks. Partially-implement: blueprint core-vendor-decomposition Change-Id: I4510aaa74c8853278b1c17757d4f4fa67554093a --- doc/source/devref/contribute.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/source/devref/contribute.rst b/doc/source/devref/contribute.rst index 0b2f2021b..ce957d747 100644 --- a/doc/source/devref/contribute.rst +++ b/doc/source/devref/contribute.rst @@ -221,12 +221,12 @@ make sense depending on whether you are contributing a new or existing plugin or driver. If you are contributing a new plugin, the approach to choose should be based on -`Extras.d Hooks `_. +`Extras.d Hooks' externally hosted plugins `_. With the extra.d hooks, the DevStack integration is colocated with the vendor integration library, and it leads to the greatest level of flexibility when dealing with DevStack based dev/test deployments. -Having said that, most Neutron Plugins developed in the past likely already have +Having said that, most Neutron plugins developed in the past likely already have integration with DevStack in the form of `neutron_plugins `_. If the plugin is being decomposed in vendor integration plus vendor library, it would be necessary to adjust the instructions provided in the neutron_plugin file to pull the -- 2.45.2