Open Stack

Got it!
I will file a bug for it and I will submit the fix this week.

Thanks,

Edgar

From:  Aaron Rosen <arosen at nicira.com>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Tuesday, July 2, 2013 3:33 PM
To:  OpenStack List <openstack-dev at 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 <emagana at 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 <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_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-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 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/
>>> listinfo/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/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/0ac11a11/attachment-0001.html>