Merge "spec for resource deleting"
This commit is contained in:
commit
1cbc3bb2c0
|
@ -0,0 +1,66 @@
|
|||
========================================
|
||||
Reliable resource deleting in Tricircle
|
||||
========================================
|
||||
|
||||
Background
|
||||
==========
|
||||
During the deletion of resources which are mapped to several local Neutron(s),
|
||||
it may bring some conflict operations. For example, deleting a network in
|
||||
central neutron which is also resided in several local Neutron(s). The reason
|
||||
is that network-get request will trigger local neutron to query central
|
||||
neutron and create the network, and we delete local networks before deleting
|
||||
central network. When a network-get request comes to a local neutron server
|
||||
after the local network is completely deleted in that region and at this time
|
||||
the network in central neutron still exists (assuming it takes certain time to
|
||||
delete all local networks), local neutron will still retrieve the network from
|
||||
central neutron and the deleted local network will be recreated. This issue
|
||||
also applies to the deletion cases of other resource types.
|
||||
|
||||
Proposed Solution
|
||||
=================
|
||||
Recently, Tricircle adds a feature to distinguish the source of requests[1], so
|
||||
we can distinguish the deletion request from 'Central Neutron' or
|
||||
'Local Neutron'. In order to avoid the conflict mentioned above, we introduce a
|
||||
new table called "deleting_resource" in Tricircle database, so central plugin
|
||||
can save the resource deletion information and set the information when it
|
||||
receives a deletion request. Here is the schema of the table:
|
||||
|
||||
.. csv-table:: Resource deleting table
|
||||
:header: Field, Type, Nullable, pk/fk/uk, Description
|
||||
|
||||
resource_id, string, False, uk, resource id in central Neutron
|
||||
resource_type, string, False, uk, resource_type denotes one of the available resource types
|
||||
deleted_at, timestamp, False, n/a, deletion timestamp
|
||||
|
||||
**How to delete the resource without conflict operation**
|
||||
|
||||
Let's take network deletion as an example.
|
||||
|
||||
At the beginning of network-delete handle, central neutron server sets the
|
||||
information of deleted network into the "deleting_resource" table.
|
||||
|
||||
At this point, if get-request from local neutron servers comes, central
|
||||
neutron server will check the "deleting_resource" table whether the
|
||||
associated resource has been recorded and return 404 to local neutron server
|
||||
if the associated resources is being deleting.
|
||||
|
||||
At this point, if deletion request is from central Neutron, central neutron
|
||||
server will check the "deleting_resource" table whether the associated
|
||||
resource has been recorded and it will return 204 to user if associated
|
||||
resource is being deleting.
|
||||
|
||||
For the get-request of user, central neutron server will query the related
|
||||
network information in "deleting_resource" table and will return the deleting
|
||||
resource to user if the network information which the user queries exists in
|
||||
the table. When user re-deleting the network after something wrong happens,
|
||||
central neutron will return 204 to user.
|
||||
|
||||
At the end of network-delete handle that all the mapped local networks have
|
||||
been deleted, central neutron server will remove the deleting resource record
|
||||
and remove this network.
|
||||
|
||||
In addition, there is a timestamp in table that cloud administrator is able to
|
||||
delete a resource which is in deleting status over long time (too long to
|
||||
delete, or in abnormal status).
|
||||
|
||||
[1] https://review.openstack.org/#/c/518421/
|
Loading…
Reference in New Issue