From 2d8b7a6bbf308880a7c5795c5bdfc39bd8c3586f Mon Sep 17 00:00:00 2001 From: armando-migliaccio Date: Mon, 5 Oct 2015 10:15:34 -0700 Subject: [PATCH] Adding Effective tips for plugin development Change-Id: I4384e4476e7081b0ebfabc7367d32c683cc4d58d --- doc/source/devref/effective_neutron.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/doc/source/devref/effective_neutron.rst b/doc/source/devref/effective_neutron.rst index 89500f546..d74f9e2e8 100644 --- a/doc/source/devref/effective_neutron.rst +++ b/doc/source/devref/effective_neutron.rst @@ -54,6 +54,25 @@ Happy hacking! Developing better software -------------------------- +Plugin development +~~~~~~~~~~~~~~~~~~ + +Document common pitfalls as well as good practices done during plugin development. + +* Use mixin classes as last resort. They can be a powerful tool to add behavior + but their strength is also a weakness, as they can introduce `unpredictable `_ + behavior to the `MRO `_, + amongst other issues. +* If you make changes to the DB class methods, like calling methods that can + be inherited, think about what effect that may have to plugins that have + controller `backends `_. +* If you make changes to the ML2 plugin or components used by the ML2 plugin, + think about the `effect `_ + that may have to other plugins. +* When adding behavior to the L2 and L3 db base classes, do not assume that + there is an agent on the other side of the message broker that interacts + with the server. Plugins may not rely on `agents `_ at all. + Database interaction ~~~~~~~~~~~~~~~~~~~~ -- 2.45.2