Unhandled UnboundLocalError in IPAssociationWorkflow

[Brian DeHamer]

If an error is raised in the AssociateIPAction we assume that a redirect will be raised. However, certain exception classes will not result in a redirect when handled by the standard Horizon exception handler.

The two problem spots are in AssociateIPAction.populate_ip_id_choices (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py#L68) and AssociateIPAction. populate_instance_id_choices (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py#L84)

If the error handler doesn't raise a redirect, control will be returned to the statement after the 'except' block but some of the necessary variables may be unbound.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/79641

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/79641
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=e686fb8520a1a2ea87bc70689af7fd262160e982
Submitter: Jenkins
Branch: master

commit e686fb8520a1a2ea87bc70689af7fd262160e982
Author: Brian DeHamer <email address hidden>
Date: Tue Mar 11 08:40:12 2014 -0700

    Fix unbound locals in IPAssociationWorkflow

    If an error is raised in the AssociateIPAction we assume that a redirect
    will be raised. However, certain exception classes will not result in a
    redirect when handled by the standard Horizon exception handler. If the
    error handler doesn't re-raise some sort of error, control will be
    returned to the statement after the except block and some of the
    necessary local variables may be unbound.

    This fix simply ensures that all of the necessary locals are bound in
    the event that an error does occur.

    Change-Id: Ib8c92ab218457e51e521d36bb4778c1dc1025342
    Closes-Bug: #1290583