Open Stack

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
>>> 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-Project-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.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
>>
>>
> _______________________________________________ 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/db3a3764/attachment.html>