| *** mikecmpbll has joined #openstack-swift | 00:45 | |
| *** psachin has joined #openstack-swift | 03:04 | |
| *** mikecmpbll has quit IRC | 03:42 | |
| *** hoonetorg has joined #openstack-swift | 06:22 | |
| *** e0ne has joined #openstack-swift | 07:23 | |
| *** psachin has quit IRC | 07:45 | |
| *** e0ne has quit IRC | 07:47 | |
| *** e0ne has joined #openstack-swift | 08:00 | |
| *** gkadam has joined #openstack-swift | 08:01 | |
| *** e0ne has quit IRC | 08:05 | |
| *** ccamacho has joined #openstack-swift | 08:06 | |
| *** mikecmpbll has joined #openstack-swift | 08:22 | |
| *** mikecmpbll has quit IRC | 08:40 | |
| *** mikecmpbll has joined #openstack-swift | 09:02 | |
| *** hseipp has joined #openstack-swift | 09:56 | |
| *** ybunker has joined #openstack-swift | 14:18 | |
| ybunker | hi all, quick question... how can i access to .expiring_objects account? i would like to know if an object that has disappeared from a cluster was being hitting by the object-expirer daemon or not, I can't find the object on the logs and the customer has confirm us that until last week the object GETs work fine | 14:25 |
|---|---|---|
| rledisez | ybunker: you should be able to check your object-expirer logs, something like: | 14:28 |
| rledisez | Feb 11 15:26:46 127.0.0.1 object-expirer: - - 11/Feb/2019/14/26/46 DELETE /v1/AUTH_… HTTP/1.0 204 - Swift%20Object%20Expirer - - - - txe99ea7dc975144e7bcf3a-005c618626 - 0.6796 - - 1549895206.308103085 1549895206.987672091 0 | 14:28 |
| rledisez | var/log/swift/object-expirer.log by default IIRW | 14:29 |
| ybunker | rledisez:..mmm i don't have the object-expirer.log file... also the process was running, and doing some grep on the proxy logs, can't find any DELETE operation | 14:31 |
| *** ybunker has quit IRC | 14:36 | |
| *** hoonetorg has quit IRC | 15:09 | |
| *** hoonetorg has joined #openstack-swift | 15:27 | |
| *** ybunker has joined #openstack-swift | 15:35 | |
| *** gkadam has quit IRC | 15:49 | |
| *** ybunker has quit IRC | 15:58 | |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Display crypto data/metadata details in swift-object-info https://review.openstack.org/586903 | 16:02 |
| *** e0ne has joined #openstack-swift | 16:04 | |
| *** e0ne has quit IRC | 16:17 | |
| *** onovy has quit IRC | 16:19 | |
| *** onovy has joined #openstack-swift | 16:19 | |
| *** e0ne has joined #openstack-swift | 16:21 | |
| *** e0ne has quit IRC | 16:26 | |
| notmyname | good morning | 16:33 |
| *** e0ne has joined #openstack-swift | 16:36 | |
| *** ybunker has joined #openstack-swift | 17:16 | |
| *** e0ne has quit IRC | 17:20 | |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Display crypto data/metadata details in swift-object-info https://review.openstack.org/586903 | 17:20 |
| *** gyee has joined #openstack-swift | 17:24 | |
| timburke | clayg: so one thought i had over the weekend about the reconstructor change... with a two-region EC policy, four primaries do a local-remote-remote sync | 17:40 |
| *** mikecmpbll has quit IRC | 17:41 | |
| timburke | i really *like* the idea that every node should be responsible for *a* remote sync... and if we get up to three or more regions, I'm not so worried... but I wonder if it might be better *in this particular case* to wrap back around to the start of *our* region when we're the first/last node for the region | 17:43 |
| clayg | yes, I think it would be interesting to optimize the frag duplicated EC rebalance/reconstruct case | 17:45 |
| clayg | what's the biggest win of all the things we can do? probably trying to do a sync from the duplicate instead of rebuild? | 17:46 |
| clayg | unless you want to optimize for local traffic over wan... hrmmm... | 17:46 |
| clayg | honestly probably if we have bandwidth for multi-region cluster enhancements we should look at metadata requests | 17:47 |
| clayg | idk... | 17:47 |
| *** zaitcev has joined #openstack-swift | 17:50 | |
| *** ChanServ sets mode: +v zaitcev | 17:50 | |
| timburke | the one special case i just mentioned should be cheap -- direct copy of a matching frag seems like it'd do more good | 17:52 |
| timburke | what do you mean "metadata requests"? | 17:52 |
| timburke | clayg: is the reconstructor at all read-affinity-aware? | 17:55 |
| clayg | no. it blasts concurrent requests to all primaries | 18:04 |
| clayg | basically when we added ec duplication we did no optimization for reconstructor - it "worked" so it was left to do what it already did | 18:04 |
| *** hseipp has quit IRC | 18:12 | |
| *** mikecmpbll has joined #openstack-swift | 18:26 | |
| timburke | boo! sharder probe tests are using the raw swiftclient.client.delete_object api instead of at least using swiftclient.client.Connection.delete_object which would include retries :-( http://logs.openstack.org/03/586903/6/check/swift-probetests-centos-7/53d30ac/job-output.txt.gz#_2019-02-11_18_01_28_142105 | 18:41 |
| zaitcev | hmm | 18:41 |
| *** openstackgerrit has quit IRC | 18:51 | |
| *** ybunker has quit IRC | 18:55 | |
| *** mvkr has quit IRC | 19:10 | |
| *** e0ne has joined #openstack-swift | 19:41 | |
| *** mikecmpbll has quit IRC | 19:45 | |
| *** gyee has quit IRC | 19:52 | |
| *** gyee has joined #openstack-swift | 20:00 | |
| *** e0ne has quit IRC | 20:08 | |
| clayg | timburke: I think if we could get probetests to run with a 20s node_timeout we'd see a lot less failures... | 20:35 |
| clayg | but tdasilva says it just uses the default/saio config - i want like a probe/gate override... I think... | 20:36 |
| timburke | clayg: https://docs.ansible.com/ansible/latest/modules/ini_file_module.html ? | 20:36 |
| clayg | oh neato - so we just need to find somewhere in one of playbooks to put it | 20:37 |
| clayg | probably just add a new `crudini` command here -> https://github.com/openstack/swift/blob/master/tools/playbooks/multinode_setup/make_rings.yaml#L55 | 20:41 |
| timburke | oh yeah -- that works, too | 20:43 |
| *** openstackgerrit has joined #openstack-swift | 20:43 | |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Increase probetest multi-node timeout https://review.openstack.org/636217 | 20:43 |
| clayg | well see if that multi-node job has the bigger timeout 🤷 | 20:44 |
| *** itlinux has joined #openstack-swift | 21:22 | |
| *** e0ne has joined #openstack-swift | 21:34 | |
| *** itlinux has quit IRC | 21:35 | |
| *** e0ne has quit IRC | 21:41 | |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Increase node_timeout in gate https://review.openstack.org/636217 | 21:48 |
| clayg | so i guess i was confused about all the different jobs we have and which setups go where - maybe there is better - maybe there's some more playbooks we should update? 🤷♂️ | 21:49 |
| tdasilva | clayg: yeah, i think our jobs definition is a bit messy atm, i have this TODO about organizing them a bit better, but haven't had a chance to get to it | 21:53 |
| tdasilva | basically i'd like to eventually change them to something similar we did with libec | 21:53 |
| clayg | oh? is libec nice? | 21:54 |
| tdasilva | yeah, it's nice in the sense that we defined roles: https://github.com/openstack/liberasurecode/blob/master/playbooks/unittests/run.yaml | 21:55 |
| tdasilva | and now we should be able to re-use those same roles in pyeclib | 21:55 |
| timburke | huh. i'm trying to decide if this is *also* resource-constrained-gate: http://logs.openstack.org/17/636217/2/check/swift-probetests-centos-7/009a2ba/job-output.txt.gz#_2019-02-11_22_02_27_451197 | 22:50 |
| timburke | i don't think i've seen *that* one before | 22:50 |
| mattoliverau | morning | 22:55 |
| *** tkajinam has joined #openstack-swift | 22:57 | |
| *** mvkr has joined #openstack-swift | 23:08 | |
| *** mikecmpbll has joined #openstack-swift | 23:15 | |
| *** rchurch_ has joined #openstack-swift | 23:21 | |
| *** rchurch has quit IRC | 23:23 | |
| *** jistr_ has joined #openstack-swift | 23:39 | |
| *** onovy has quit IRC | 23:46 | |
| *** jistr has quit IRC | 23:46 | |
| *** thyrst has quit IRC | 23:46 | |
| *** fyx has quit IRC | 23:46 | |
| *** coreycb has quit IRC | 23:46 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!