Open Stack

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 <arosen at nicira.com>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Tuesday, July 2, 2013 2:28 PM
To:  OpenStack List <openstack-dev at 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 <emagana at 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 <arosen at nicira.com>
> Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
> Date:  Tuesday, July 2, 2013 1:55 PM
> 
> To:  OpenStack List <openstack-dev at 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 <emagana at 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 <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_v2
>> .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-Pr
>>> oject-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-Na
>>> me,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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> _______________________________________________ OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/l
>> istinfo/openstack-dev
>> 
>> _______________________________________________
>> 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.orghttp://lists.openstack.org/cgi-bin/mailman/li
> stinfo/openstack-dev
> 
> _______________________________________________
> 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/f318a55e/attachment.html>