neutron-vpn-agent fails to start post-upgrade

Bug #1355429 reported by Adam Gandelman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
devstack
Fix Released
Undecided
Adam Gandelman
grenade
Invalid
Undecided
Unassigned

Bug Description

Attempting to run a grenade test against a neutron-enabled cloud, ends up with the neutron-vpn-agent failing to start on the target side:

$ cd /opt/stack/new/neutron && /usr/local/bin/neutron-vpn-agent --config-file /etc/neutron/fwaas_driver.ini || echo "q-vpn failed to start" | tee "/opt/stack/status/stack/q-vpn.failure"
2014-08-11 13:14:49.514 7949 ERROR neutron.agent.l3_agent [-] An interface driver must be specified
q-vpn failed to start

It appears the required '--config-file /etc/neutron/l3_agent.ini' arg is not being passed when the service is restarted.

Revision history for this message
Adam Gandelman (gandelman-a) wrote :

This is similar to https://bugs.launchpad.net/devstack/+bug/1310858.

lib/neutron is a bit of a mess and the dependencies between the functions that start services and those that configure them is very unclear. Many of the files default config paths as well as the arguments that get passed to service binaries get set within configuration functions and later re-used by those that start functions. With grenade importing lib/neutron and only calling the latter start functions on the far side of the upgrade, it loses some required context. Ie, in the case of this bug the vpn agent must be passed '-$L3_CONF_FILES':

function start_neutron_agents {
    ...
    if is_service_enabled q-fwaas; then
        L3_CONF_FILES="$L3_CONF_FILES --config-file $Q_FWAAS_CONF_FILE"
        VPN_CONF_FILES="$VPN_CONF_FILES --config-file $Q_FWAAS_CONF_FILE"
    fi
    if is_service_enabled q-vpn; then
        screen_it q-vpn "cd $NEUTRON_DIR && $AGENT_VPN_BINARY $VPN_CONF_FILES"
    else
        screen_it q-l3 "cd $NEUTRON_DIR && python $AGENT_L3_BINARY $L3_CONF_FILES"
    fi
   ....
}

function _configure_neutron_l3_agent {
     ...
      if is_service_enabled q-vpn; then
        Q_VPN_CONF_FILE=$NEUTRON_CONF_DIR/vpn_agent.ini
        cp $NEUTRON_DIR/etc/vpn_agent.ini $Q_VPN_CONF_FILE
        VPN_CONF_FILES="--config-file $NEUTRON_CONF --config-file=$Q_L3_CONF_FILE --config-file=$Q_VPN_CONF_FILE"
        for cfg_file in ${Q_VPN_EXTRA_CONF_FILES[@]}; do
            VPN_CONF_FILES+=" --config-file $cfg_file"
        done
}

grenade does not call the configure code as part of the upgrade, and hence the agent never receives proper arguments on post-upgrade restart.

Changed in devstack:
assignee: nobody → Adam Gandelman (gandelman-a)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to devstack (master)

Reviewed: https://review.openstack.org/113377
Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=7614d21fe157a6b3a833d3eb278fb9267ef13e06
Submitter: Jenkins
Branch: master

commit 7614d21fe157a6b3a833d3eb278fb9267ef13e06
Author: Adam Gandelman <email address hidden>
Date: Mon Aug 11 14:27:50 2014 -0700

    Centralize neutron config file argument generation

    Moves dynamic generation of the --config-file list from local functions
    to global utility functions. This breaks up the current non-obvious
    dependency between start_neutron_agents and _configure_neutron_l3_agent
    for setting the correct arguments for the vpn agent. This also similarly
    updates generation of arguments for neutron-server and neutron-l3-agent to
    use said functions. Finally, this cleans lib/neutron up a bit and moves
    all default paths to config files and binaries out of local functions and
    into the top-level, allowing external tools like Grenade to make use of the
    library for starting Neutron services and agents currently.

    Change-Id: I927dafca8a2047d6c0fd3c74569ed2521f124547
    Closes-bug: #1355429

Changed in devstack:
status: In Progress → Fix Released
Revision history for this message
Sean Dague (sdague) wrote :

This grenade bug was last updated over 180 days ago, as grenade
is a fast moving project and we'd like to get the tracker down to
currently actionable bugs, this is getting marked as Invalid. If the
issue still exists, please feel free to reopen it.

Changed in grenade:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.