If the plugin performs operations when the subnet is created, how is possible to roll-back those operation if the plugin implementation of delete_subnet() is never called? I donĀ¹t think we should let delete_network in debasepluginv2.py delete all subnets, we could just ask the tenant user to delete all subnets first, is there any specific reason why we automatically delete all subnets?
Edgar From: Aaron Rosen <aro...@nicira.com> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> Date: Tuesday, July 2, 2013 12:40 PM To: OpenStack List <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Neutron] does delete_network call delete_subnet automatically? delete_network() in the db_base class handles deleting the subnets associated with the networks. https://github.com/openstack/quantum/blob/master/quantum/db/db_base_plugin_v 2.py#L1033 On Tue, Jul 2, 2013 at 12:31 PM, Edgar Magana <emag...@plumgrid.com> wrote: > Folks, > > When I create a network and a subnet associated to that network, I am able to > delete the network without deleting the subnet first from both CLI and > Horizon. > The difference is that in Horizon, both APIs are called: delete_subnet() and > delete_network() > When I tried by CLI, only delete_network is called as you can see in these > logs: > > 2013-07-02 12:26:57 DEBUG [quantum.policy] loading policy file at > /etc/quantum/policy.json > 2013-07-02 12:26:57 DEBUG > [quantum.plugins.plumgrid.plumgrid_nos_plugin.plumgrid_plugin] > QuantumPluginPLUMgrid Status: delete_network() called > 2013-07-02 12:26:57 DEBUG [quantum.policy] loading policy file at > /etc/quantum/policy.json > 2013-07-02 12:26:57 DEBUG > [quantum.plugins.plumgrid.plumgrid_nos_plugin.rest_connection] > PLUMgrid_NOS_Server: 10.1.2.43 8080 DELETE > 2013-07-02 12:26:57 DEBUG > [quantum.plugins.plumgrid.plumgrid_nos_plugin.rest_connection] > PLUMgrid_NOS_Server Sending Data: {'Content-type': 'application/json', > 'Accept': 'application/json'} > 2013-07-02 12:26:57 DEBUG [quantum.openstack.common.rpc.amqp] Sending > network.delete.end on notifications.info <http://notifications.info> > 2013-07-02 12:26:57 DEBUG [quantum.openstack.common.rpc.amqp] UNIQUE_ID is > ad8c5a233bd6403ea850cde73afb720a. > 2013-07-02 12:26:57 DEBUG [quantum.openstack.common.rpc.amqp] Making > asynchronous fanout cast... > 2013-07-02 12:26:57 DEBUG [quantum.openstack.common.rpc.amqp] UNIQUE_ID is > dcba5e2b55bb4cb89aab17f5797882e6. > 2013-07-02 12:27:23 DEBUG [keystoneclient.middleware.auth_token] > Authenticating user token > 2013-07-02 12:27:23 DEBUG [keystoneclient.middleware.auth_token] Removing > headers from request environment: > X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Proj > ect-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-U > ser-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-T > enant,X-Role > 2013-07-02 12:27:23 DEBUG [keystoneclient.middleware.auth_token] Storing > dd0bd438481c2d010d1abc5903fa11da token in memcache > 2013-07-02 12:27:23 DEBUG [routes.middleware] No route matched for GET > /subnets.json > 2013-07-02 12:27:23 DEBUG [routes.middleware] Matched GET /subnets.json > 2013-07-02 12:27:23 DEBUG [routes.middleware] Route path: > '/subnets{.format}', defaults: {'action': u'index', 'controller': <wsgify at > 37764240 wrapping <function resource at 0x24745f0>>} > 2013-07-02 12:27:23 DEBUG [routes.middleware] Match dict: {'action': > u'index', 'controller': <wsgify at 3776424 > > However, the subnet is not in the DB but the delete_subnet API is never > called, can somebody explain what is happening here? > BTW. This is Grizzly release > > Thanks, > > Edgar > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev