Open Stack

On Fri, Apr 28 2017, gordon chung wrote:

>>> if the sack is unlocked, then it means a processing worker isn't looking
>>> at the sack, and when it does lock the sack, it first has to check sack
>>> for existing measures to process and then check indexer to validate that
>>> they are still active. because it checks indexer later, even if both
>>> janitor and processing worker check lock at same time, we can guarantee
>>> it will have indexer state processing worker sees is > 00:00:00 since
>>> janitor has state before getting lock, while processing worker as state
>>> sometime after getting lock.
>>
>> My brain hurts but that sounds perfect. That even means we potentially
>> did not have to lock currently, sack or no sack.
>>
>
> oh darn, i didn't consider multiple janitors... so this only works if we 
> make janitor completely separate and only allow one janitor ever. back 
> to square 1

Not sure it's a big deal if you have multiple janitors. Do you have a
scenario in mind where we'd have problem?
Since it's mainly:
1. get 'deleted' metrics
2. delete all things in storage
  -> if it fails, whatever, ignore, maybe a janitor is doing the same
  thing?
3. expunge from indexer

I miss something hm?

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170429/3f437112/attachment.sig>