Merge "spec for resource deleting"

specs/queens/resource_deleting.rst

@@ -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/