Open Stack

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 <arosen at nicira.com>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Tuesday, July 2, 2013 12:40 PM
To:  OpenStack List <openstack-dev at 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 <emagana at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

_______________________________________________ OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130702/cd956d9e/attachment.html>