Version: Folsom on RHEL6.4 One controller and 2 compute nodes, FlatDHCPManager openstack-nova-objectstore-2012.2.2-6.el6ost.noarch openstack-nova-compute-2012.2.2-6.el6ost.noarch python-nova-2012.2.2-6.el6ost.noarch openstack-nova-volume-2012.2.2-6.el6ost.noarch openstack-nova-2012.2.2-6.el6ost.noarch python-novaclient-2.10.0-1.el6ost.noarch openstack-nova-common-2012.2.2-6.el6ost.noarch openstack-nova-console-2012.2.2-6.el6ost.noarch openstack-nova-cert-2012.2.2-6.el6ost.noarch openstack-nova-novncproxy-0.4-2.el6.noarch openstack-nova-api-2012.2.2-6.el6ost.noarch openstack-nova-scheduler-2012.2.2-6.el6ost.noarch openstack-nova-network-2012.2.2-6.el6ost.noarch Scenario: While trying to delete a network, network deletion requires disassociation from the project as a preliminary step. The command for network disassociation from a project returns successfully but it practice does NOT disassociate the network from the project. Additional Information: [root@puma10 nova(keystone_admin)]$ nova-manage network modify 192.168.11.128/25 --disassociate-project fa1862b54f0443b9a396b7b45aab6d8a 2013-01-21 15:28:27 DEBUG nova.utils [req-982e1d7e-43b2-4ae4-9e5c-efb7a0861ca0 None None] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/python2.6/site-packages/nova/db/sqlalchemy/api.pyc'> __get_backend /usr/lib/python2.6/site-packages/nova/utils.py:502 [root@puma10 nova(keystone_admin)]$ echo $? 0 [root@puma10 nova(keystone_admin)]$ nova-manage network list id IPv4 IPv6 start address DNS1 DNS2 VlanID project uuid 2013-01-21 15:28:42 DEBUG nova.utils [req-3de7df15-c31f-4597-b20e-b25d5407a345 None None] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/python2.6/site-packages/nova/db/sqlalchemy/api.pyc'> __get_backend /usr/lib/python2.6/site-packages/nova/utils.py:502 1 192.168.1.0/24 None 192.168.1.2 8.8.4.4 None None None 6912f764-b491-4d5e-8380-08cd46b9d62e 2 192.168.10.128/25 None 192.168.10.130 8.8.4.4 None None some_project_uuid 4b7c337c-56d4-4c2d-a439-496b2246be5b 3 192.168.11.128/25 None 192.168.11.130 8.8.4.4 None None fa1862b54f0443b9a396b7b45aab6d8a 8064eeb8-325d-46c7-9075-963c83077383 [root@puma10 nova(keystone_admin)]$ nova-manage network delete 192.168.11.128/25 2013-01-21 15:29:50 DEBUG nova.utils [req-08043470-7a3c-4fb9-9361-c43c1a14519c None None] Reloading cached file /etc/nova/policy.json read_cached_file /usr/lib/python2.6/site-packages/nova/utils.py:1137 2013-01-21 15:29:51 DEBUG nova.utils [req-08043470-7a3c-4fb9-9361-c43c1a14519c None None] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/python2.6/site-packages/nova/db/sqlalchemy/api.pyc'> __get_backend /usr/lib/python2.6/site-packages/nova/utils.py:502 Command failed, please check log for more info 2013-01-21 15:29:51 CRITICAL nova [req-08043470-7a3c-4fb9-9361-c43c1a14519c None None] Network must be disassociated from project fa1862b54f0443b9a396b7b45aab6d8a before delete 2013-01-21 15:29:51 9103 TRACE nova Traceback (most recent call last): 2013-01-21 15:29:51 9103 TRACE nova File "/usr/bin/nova-manage", line 1403, in <module> 2013-01-21 15:29:51 9103 TRACE nova main() 2013-01-21 15:29:51 9103 TRACE nova File "/usr/bin/nova-manage", line 1390, in main 2013-01-21 15:29:51 9103 TRACE nova fn(*fn_args, **fn_kwargs) 2013-01-21 15:29:51 9103 TRACE nova File "/usr/bin/nova-manage", line 532, in delete 2013-01-21 15:29:51 9103 TRACE nova fixed_range, uuid) 2013-01-21 15:29:51 9103 TRACE nova File "/usr/lib/python2.6/site-packages/nova/network/manager.py", line 266, in wrapped 2013-01-21 15:29:51 9103 TRACE nova return func(self, context, *args, **kwargs) 2013-01-21 15:29:51 9103 TRACE nova File "/usr/lib/python2.6/site-packages/nova/network/manager.py", line 1615, in delete_network 2013-01-21 15:29:51 9103 TRACE nova ' before delete') % network.project_id) 2013-01-21 15:29:51 9103 TRACE nova ValueError: Network must be disassociated from project fa1862b54f0443b9a396b7b45aab6d8a before delete 2013-01-21 15:29:51 9103 TRACE nova [root@puma10 nova(keystone_admin)]$
It should be determined whether this is a nova-manage bug or an actual nova issue before getting a true prioritization re: snapshots, etc.
This is a bug in nova-manage. Starting on line 565: 565 if project: 566 net['project_id'] = project 567 elif dis_project: 568 net['project_id'] = None The if/elif is wrong. I could be written as: 565 if dis_project: 566 net['project_id'] = None 567 elif project: 568 net['project_id'] = project or 565 if project: 566 net['project_id'] = project 567 if dis_project: 568 net['project_id'] = None or some other equivalent form.
Actually, the real issue appears to be that the --disassociate-X commands are not meant to take arguments at all. The "network modify" function can go haywire if you put anything after --disassociate-host or --disassociate-project (does it do positional parameter placement in this case?) In any case, the code could be hardened by having the --dissociate-X directives be "exclusive" (ie. you can only run one modification at a time.
Patch for changed behavior submitted upstream: https://review.openstack.org/#/c/21447/
Verified on 2012.2.3-4.el6ost, now network deletion by nova-manage works without exception on disassociation issues, and network disassociation command works well - now the project uuid should not appear in the disassociation syntax.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0657.html