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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
