Hi, GibiĀ <div><br></div><div>Yes, soft_delete.end notification didn't got handled in SL, and we should do it, but what Matt mean here is deferent, even you 'hard' delete an instance the record still exists in DB and user with certain role can list it using deleted=true, so we should also do it in SL<br><br>On Monday, March 6, 2017, Balazs Gibizer <<a href="mailto:balazs.gibizer@ericsson.com">balazs.gibizer@ericsson.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Mon, Mar 6, 2017 at 3:09 AM, Zhenyu Zheng <<a>zhengzhenyulixi@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, Matt<br>
<br>
AFAIK, searchlight did delete the record, it catch the instance.delete notification and perform the action:<br>
<a href="http://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/elasticsearch/plugins/nova/notification_handler.py#n100" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/searchlight/tree/sea<wbr>rchlight/elasticsearch/plugins<wbr>/nova/notification_handler.py#<wbr>n100</a><br>
-> <a href="http://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/elasticsearch/plugins/nova/notification_handler.py#n307" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/searchlight/tree/sea<wbr>rchlight/elasticsearch/plugins<wbr>/nova/notification_handler.py#<wbr>n307</a><br>
</blockquote>
<br>
Hi,<br>
<br>
There is instance.soft_delete legacy notification [2] (delete_type == 'soft_delete'). This could be transformed to versioned notification along with [3]. So I guess there could be a way to distinguish between soft delete and real delete on searchlight side based on these notifications.<br>
<br>
Cheers,<br>
gibi<br>
<br>
[2] <a href="https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1872" target="_blank">https://github.com/openstack/n<wbr>ova/blob/master/nova/compute/a<wbr>pi.py#L1872</a><br>
[3] <a href="https://review.openstack.org/#/c/410297/" target="_blank">https://review.openstack.org/#<wbr>/c/410297/</a><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I will double check with others from the SL team, and if it is the case, we will try to find a way to solve this ASAP.<br>
<br>
Thanks,<br>
<br>
Kevin Zheng<br>
<br>
On Mon, Mar 6, 2017 at 1:21 AM, Matt Riedemann <<a>mriedemos@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've posted a spec [1] for nova's integration with searchlight for listing instance across multiple cells. One of the open questions I have on that is when/how do instances get removed from searchlight?<br>
<br>
When an instance gets deleted via the compute API today, it's not really deleted from the database. It's considered "soft" deleted and you can still list (soft) deleted instances from the database via the compute API if you're an admin.<br>
<br>
Nova will be sending instance.destroy notifications to searchlight but we don't really want the ES entry removed because we still have to support the compute API contract to list deleted instances. Granted, this is a pretty limp contract because there is no guarantee that you'll be able to list those deleted instances forever because once they get archived (moved to shadow tables in the nova database) or purged (hard delete), then they are gone from that API query path.<br>
<br>
So I'm wondering at what point instances stored in searchlight will be removed. Maybe there is already an answer to this and the searchlight team can just inform me. Otherwise we might need to think about data retention policies and how long a deleted instances will be stored in searchlight before it's removed. Again, I'm not sure if nova would control this or if it's something searchlight supports already.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/441692/" target="_blank">https://review.openstack.org/#<wbr>/c/441692/</a><br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div>