Got it! I will file a bug for it and I will submit the fix this week. Thanks,
Edgar From: Aaron Rosen <aro...@nicira.com> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> Date: Tuesday, July 2, 2013 3:33 PM To: OpenStack List <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Neutron] does delete_network call delete_subnet automatically? The call should be in the db_base class. If you call self.delete_subnet() from the db_base class then it will call the delete_subnet() method from the plugin if implement. Inheritance. On Tue, Jul 2, 2013 at 3:15 PM, Edgar Magana <emag...@plumgrid.com> wrote: > It makes sense totally. Then, instead of making the db_base class calling the > delete_subnet at the plugin level, shouldn't be better call delete_subnet at > the plugin level when the delete_network is called? > Basically: > > def delete_network() > subnets = get_subnets() > for subnet in subnets: > delete_subnet(subnet) > > > Edgar > > From: Aaron Rosen <aro...@nicira.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Tuesday, July 2, 2013 2:28 PM > > To: OpenStack List <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron] does delete_network call delete_subnet > automatically? > > Yes, I think this is the desired behavior. If someone deletes a network we > check to see if there are any ports on the network. If there are ports on the > network we raise. If there are no ports on the network we allow it to be > deleted. Since you cannot have a subnet without a network we should delete > that then too. I don't see any reason to complicate things by forcing the user > to delete the subnets first. > > Aaron > > > On Tue, Jul 2, 2013 at 2:04 PM, Edgar Magana <emag...@plumgrid.com> wrote: >> Before filing a bug, do we really want this kind of functionality? >> Is it "correct" to delete a network without really checking if the owner >> really wants to delete all subnets associated with it? >> >> Edgar >> >> From: Aaron Rosen <aro...@nicira.com> >> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> >> Date: Tuesday, July 2, 2013 1:55 PM >> >> To: OpenStack List <openstack-dev@lists.openstack.org> >> Subject: Re: [openstack-dev] [Neutron] does delete_network call >> delete_subnet automatically? >> >> Good point. We should be calling delete_subnet() from delete_network() in the >> db_base class rather than deleting it directly from the database. >> >> Aaron >> >> >> On Tue, Jul 2, 2013 at 1:39 PM, Edgar Magana <emag...@plumgrid.com> wrote: >>> 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-P >>>> roject-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain- >>>> Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant >>>> -Name,X-Tenant,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.orghttp://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.orghttp://lists.openstack.org/cgi-bin/mailman/l >> istinfo/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.orghttp://lists.openstack.org/cgi-bin/mailman/li > stinfo/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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev