openstack/devstack
Code Issues Proposed changes
b889294af7
devstack/lib/neutron_plugins
History
Ian Wienand 523f488036 Namespace XTRACE commands 
I noticed this when debugging some grenade issues failures.

An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.

We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.

When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).

The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.

The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.

Some files had already discovered this.  In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste.  This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.

Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
2015-11-27 15:36:04 +11:00
..
services Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
bigswitch_floodlight Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
brocade Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
cisco Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
embrane Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
linuxbridge_agent Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
midonet midonet: Provide has_neutron_plugin_security_group 2015-06-03 17:12:59 +09:00
ml2 Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
nec neutron-nec: Vendor code split 2015-03-08 18:27:14 +09:00
nuage Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
openvswitch Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
openvswitch_agent Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
ovs_base Namespace XTRACE commands 2015-11-27 15:36:04 +11:00
README.md Remove NOVA_VIF_DRIVER variable 2015-08-25 13:40:25 -07:00
vmware_dvs VMware: add support for simple DVS 2015-05-25 01:09:06 -07:00
vmware_nsx vmware-nsx: Vendor code split 2015-03-03 02:04:29 -08:00
vmware_nsx_v vmware-nsx: Vendor code split 2015-03-03 02:04:29 -08:00
vmware_nsx_v3 Add vmware_nsx_v3 support 2015-06-09 13:16:12 -07:00

README.md

Neutron plugin specific files

Neutron plugins require plugin specific behavior. The files under the directory, lib/neutron_plugins/, will be used when their service is enabled. Each plugin has lib/neutron_plugins/$Q_PLUGIN and define the following functions. Plugin specific configuration variables should be in this file.

  • filename: $Q_PLUGIN
    • The corresponding file name MUST be the same to plugin name $Q_PLUGIN. Plugin specific configuration variables should be in this file.

functions

lib/neutron-legacy calls the following functions when the $Q_PLUGIN is enabled

  • neutron_plugin_create_nova_conf : optionally set options in nova_conf
  • neutron_plugin_install_agent_packages : install packages that is specific to plugin agent e.g. install_package bridge-utils
  • neutron_plugin_configure_common : set plugin-specific variables, Q_PLUGIN_CONF_PATH, Q_PLUGIN_CONF_FILENAME, Q_PLUGIN_CLASS
  • neutron_plugin_configure_debug_command
  • neutron_plugin_configure_dhcp_agent
  • neutron_plugin_configure_l3_agent
  • neutron_plugin_configure_plugin_agent
  • neutron_plugin_configure_service
  • neutron_plugin_setup_interface_driver
  • has_neutron_plugin_security_group: return 0 if the plugin support neutron security group otherwise return 1
  • neutron_plugin_check_adv_test_requirements: return 0 if requirements are satisfied otherwise return 1