openstackgerrit | Tim Burke proposed openstack/swift master: py3: fix up swift-orphans https://review.opendev.org/670932 | 01:08 |
---|---|---|
openstackgerrit | Tim Burke proposed openstack/swift master: py3: fix object-replicator rsync output parsing https://review.opendev.org/670933 | 01:08 |
*** gyee has quit IRC | 01:14 | |
*** baojg has joined #openstack-swift | 01:42 | |
*** tkajinam has quit IRC | 02:23 | |
*** tkajinam has joined #openstack-swift | 02:24 | |
*** psachin has joined #openstack-swift | 03:26 | |
*** pcaruana has joined #openstack-swift | 05:08 | |
*** new_student1411 has joined #openstack-swift | 06:10 | |
new_student1411 | timburke I am unable to remove the `sysmeta` header `X-Remove-Account-Sysmeta-Global-Write-Ratelimit: x` using the same command as used for creating `sysmeta`. | 06:20 |
*** new_student1411 has quit IRC | 06:29 | |
*** rcernin has quit IRC | 07:00 | |
*** rdejoux has joined #openstack-swift | 07:17 | |
*** tkajinam has quit IRC | 08:25 | |
*** tesseract has joined #openstack-swift | 11:30 | |
*** tdasilva has joined #openstack-swift | 11:44 | |
*** ChanServ sets mode: +v tdasilva | 11:44 | |
*** tdasilva has quit IRC | 12:12 | |
*** tdasilva has joined #openstack-swift | 12:12 | |
*** ChanServ sets mode: +v tdasilva | 12:12 | |
*** tesseract has quit IRC | 12:53 | |
rledisez | good morning | 12:53 |
*** tesseract has joined #openstack-swift | 12:55 | |
rledisez | we have one user hitting the max_get_time=86400 of slo/dlo. I'm wondering what was the purpose of this limit? is it a "security" feature? | 12:56 |
*** sasregulus has quit IRC | 13:10 | |
*** zaitcev has joined #openstack-swift | 13:24 | |
*** ChanServ sets mode: +v zaitcev | 13:24 | |
*** psachin has quit IRC | 13:52 | |
*** zaitcev_ has joined #openstack-swift | 14:04 | |
*** ChanServ sets mode: +v zaitcev_ | 14:04 | |
*** zaitcev has quit IRC | 14:08 | |
*** zaitcev_ has quit IRC | 14:15 | |
tdasilva | 24hrs to return an obj? | 14:20 |
tdasilva | rledisez: I think the idea was just to limit for a reasonable timeout, no? from reading the comments (commit message) didn't sound like a security feature more like "just don't let this run forever" | 14:22 |
tdasilva | timburke: noticed swift-multinode-rolling-upgrade tests started passing again | 14:25 |
*** zaitcev_ has joined #openstack-swift | 14:28 | |
*** ChanServ sets mode: +v zaitcev_ | 14:28 | |
rledisez | tdasilva: it's a 12TB DLO ;) | 14:34 |
tdasilva | rledisez: heh, that's what i figured | 14:34 |
tdasilva | IIRC s3api has a nice (hidden) feature to specify the parts when downloading a MPU, which would allow a client to start parallel GETs and then stitch object back together. | 14:37 |
clayg | rledisez: I'm pretty sure the option was there to spur exactly this conversation | 15:09 |
clayg | rledisez: you can either increase the timeout - or talk to the client about maybe using range requests? | 15:10 |
*** zaitcev_ has quit IRC | 15:13 | |
*** zaitcev_ has joined #openstack-swift | 15:25 | |
*** ChanServ sets mode: +v zaitcev_ | 15:25 | |
*** e0ne has joined #openstack-swift | 15:32 | |
*** gyee has joined #openstack-swift | 15:39 | |
clayg | so i'm cleaning up some tests that want to support container servers that don't handle reverse=on correctly - which time originally fixed back in ebf0b220127b14bec7c05f1bc0286728f27f39d1 | 16:12 |
clayg | i don't think i'm really sure how I broke it 🤔 | 16:13 |
timburke | tdasilva, must've been https://github.com/openstack/requirements/commit/7ae7c4238a9d0bd8386825fac8284dc69e1b2097 | 16:27 |
tdasilva | timburke: ack | 16:30 |
timburke | tdasilva, rledisez: there's also the *published* feature of just doing Range requests -- ask for the first 10 or 100MB of the object; something large enough that small-enough objects are served immediately. if it's bigger than that, Content-Range header will tell you the full size and you can spin up parallel range requests for the remaining | 16:33 |
*** tesseract has quit IRC | 16:33 | |
tdasilva | we would be cool to build into python-swiftclient the ability to download objects using parallel range requests | 16:35 |
tdasilva | s/we/it | 16:35 |
timburke | the ?partNumber=N api would be nice to have, though; would let the client be smart about not hammering the same disks over and over as they try to grab the same 5GB segment 10MB at a time | 16:35 |
timburke | see https://bugs.launchpad.net/swift/+bug/1735284 | 16:36 |
openstack | Launchpad bug 1735284 in OpenStack Object Storage (swift) "Support partNumber query parameter on object GET" [Medium,Confirmed] | 16:36 |
timburke | tdasilva, i know at least one customer has done something similar, where they pull down the slo manifest so they can request the segments in parallel directly | 16:37 |
tdasilva | yeah, makes sense for large objects, can't imagine the frustration of starting a 12TB download only to see it fail at 11.5 TB... | 16:40 |
rledisez | tdasilva: hopefuly, our user only has a 100Mb/s, it was failing at 1TB ;) | 16:44 |
rledisez | for thid case, i'll increase the limit | 16:44 |
rledisez | but yeah, parallel download would be awesome | 16:44 |
openstackgerrit | Thiago da Silva proposed openstack/swift master: Add rolling upgrade tests https://review.opendev.org/626663 | 16:44 |
timburke | ugh. i'd actually be more ok with the timeout popping at 11TB -- if the client's smart, it'll probably still have some retries left for the last bit. at 1 of 12... it's unlikely we'd have enough retries | 16:50 |
clayg | there's some tests verifying behavior of DELETE in stack mode when some of the objects in the versioned container are expired | 17:00 |
clayg | i'm not sure if the use-case was more "don't get a 503 trying to DELETE when the COPY operation fails on the GET" or if the "skip through the list of old versions by doing HEADs before we write a pointer to one that's potentially expired" is worth the trouble 🤔 | 17:01 |
clayg | OTOH, it does have me thinking about building hardlinks from container listings in general - it's entirely possible for middleware to make a hardlink to object that will currently (or will soon) 404 - while we go out of our way to prevent that when clients do it | 17:03 |
*** aluria has quit IRC | 17:06 | |
*** e0ne has quit IRC | 17:20 | |
*** zaitcev_ has quit IRC | 18:01 | |
openstackgerrit | Tim Burke proposed openstack/swift master: py3: fix object-replicator rsync output parsing https://review.opendev.org/670933 | 18:04 |
timburke | hmm... the experimental probe test failure on https://review.opendev.org/#/c/668990/ looks spurious, but the rolling-upgrade tests are making me nervous... | 18:06 |
patchbot | patch 668990 - swift - Authors/changelog for 2.22.0 - 4 patch sets | 18:06 |
*** rdejoux has quit IRC | 18:08 | |
*** zaitcev_ has joined #openstack-swift | 18:13 | |
*** ChanServ sets mode: +v zaitcev_ | 18:13 | |
rledisez | i'm trying to write some code about task queue and I'm coming to a question: do we consider the object server as dumb? I mean, should the proxy pass through headers 2 parameters type=expirer ring=object or directly pass account=.task-expirer-object. how dumb dp we want the object-server be? | 18:53 |
timburke | i'm generally a fan of making it pretty damn dumb -- the fact that it needs to know about swift_bytes for SLOs (for example) was probably a mistake | 18:58 |
*** tdasilva has quit IRC | 19:06 | |
rledisez | proxy is the brain, got it :) | 19:10 |
*** zaitcev_ has quit IRC | 19:10 | |
*** zaitcev_ has joined #openstack-swift | 19:23 | |
*** ChanServ sets mode: +v zaitcev_ | 19:23 | |
timburke | client | 19:44 |
timburke | client's the brain ;-) proxy only becomes the brain when the client can't or won't. and the object server only takes it on when it really *has to* | 19:45 |
*** zaitcev_ has quit IRC | 20:26 | |
*** zaitcev_ has joined #openstack-swift | 20:38 | |
*** ChanServ sets mode: +v zaitcev_ | 20:38 | |
*** dasp has quit IRC | 20:45 | |
*** dasp has joined #openstack-swift | 20:47 | |
*** pcaruana has quit IRC | 21:01 | |
*** rcernin has joined #openstack-swift | 22:36 | |
*** tkajinam has joined #openstack-swift | 22:53 | |
*** zaitcev_ has quit IRC | 23:25 | |
*** zaitcev_ has joined #openstack-swift | 23:36 | |
*** ChanServ sets mode: +v zaitcev_ | 23:36 | |
mattoliverau | morning | 23:38 |
*** zaitcev_ has quit IRC | 23:53 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!