Friday, 2020-09-11

*** rcernin has quit IRC00:28
*** rcernin has joined #openstack-swift00:31
*** djhankb has quit IRC01:01
*** djhankb has joined #openstack-swift01:04
*** gyee has quit IRC02:54
*** rcernin has quit IRC03:53
*** rcernin has joined #openstack-swift04:15
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-swift04:33
*** manuvakery has joined #openstack-swift04:52
*** shanu_ has joined #openstack-swift06:27
*** rcernin has quit IRC06:28
*** rcernin has joined #openstack-swift06:45
*** rcernin has quit IRC06:45
*** rcernin has joined #openstack-swift06:46
*** manuvakery has quit IRC07:02
*** mikecmpbll has joined #openstack-swift07:54
*** rcernin has quit IRC09:10
shanu_I am developing an application which uses openstack swift in the backend which supports S3APIs as well. When I upload file using multi-part upload for two or more times using S3 access keys via cyberduck, it was noticed that multiple version of the file is created inside `*+segments` container under path `{filename}/{key}/`. When querying for versions via AWS cli using `aws s3api list-object-versions`  the09:31
shanu_object has  "VersionId": "null".  Same was verified from aws s3api head-object  were there was no key `VersionId` in the headers.09:31
shanu_Deleting the file manifest from cyberduck deletes the segments that was created lately(on 2nd upload) and the previous segments are left untouched. There is no way to determine and delete such segments of the object. The bucket is not version enabled.09:31
shanu_I am looking for a way to determine and delete such segments of the object.09:31
shanu_Also when performing similar uploads using SWIFT cli, uploading the same file again overrides the existing segments of the object. Upload was done with `swift upload --use-slo`.09:31
*** mikecmpbll has quit IRC09:57
*** mikecmpbll has joined #openstack-swift09:59
*** abelur has quit IRC10:11
*** donnyd has quit IRC10:11
*** samueldmq has quit IRC10:11
*** fyx has quit IRC10:11
*** jrosser has quit IRC10:11
*** mattoliverau has quit IRC10:11
*** corvus has quit IRC10:11
*** corvus has joined #openstack-swift10:11
*** donnyd has joined #openstack-swift10:11
*** abelur has joined #openstack-swift10:11
*** jrosser has joined #openstack-swift10:11
*** samueldmq has joined #openstack-swift10:16
*** mattoliverau has joined #openstack-swift10:16
*** tepper.freenode.net sets mode: +v mattoliverau10:16
*** tkajinam has quit IRC10:22
*** rcernin has joined #openstack-swift11:06
*** rcernin has quit IRC11:20
*** mikecmpbll has quit IRC11:26
*** mikecmpbll has joined #openstack-swift11:32
*** manuvakery has joined #openstack-swift11:47
rlediseztimburke: clayg about p 337861, the goal is to have only one instance of the object server while having different replication processes for each disk. IMHO, the same reasons we have servers_per_port for client-network apply to the replication-network. That's why we use this patch.13:01
patchbothttps://review.opendev.org/#/c/337861/ - swift - Permit to bind object-server on replication_port - 7 patch sets13:01
claygrledisez: having the process isolation seems reasonable - on servers with lots of disks in the chassis how do you balances # of client processes to # of replication processes per disk?13:07
*** rdejoux has joined #openstack-swift13:10
rledisezclayg:  right now we use the same number, I didn't take time to split that. we usually use 2 or 413:14
claygit seems reasonable to me that we'd support it - is that patch ready to go?  i don't hear you complaining about getting it merged every week 😁13:15
claygi haven't seen zaitcev in a few 😞13:15
rledisezwe've been running it in production for few years now, so I guess it's "okay" :)13:15
claygshanu_: the swift command line client does  a HEAD request on the object before overwriting it, if it's a SLO it will do a multipart-manifest=delete https://docs.openstack.org/swift/latest/overview_large_objects.html#deleting-a-large-object13:17
claygI thought s3api emulation tries to do something similar, but I didn't see the code for it any bug so i'm not sure...13:17
claygshanu_: but yeah it looks like s3api leaves orphan segments behind in the +segments container on overwrites pretty reliably13:20
*** mikecmpbll has quit IRC13:59
*** mikecmpbll has joined #openstack-swift14:01
*** gmann is now known as gmann_afk14:05
openstackgerritClay Gerrard proposed openstack/swift master: add swift-manage-shard-ranges shrink command  https://review.opendev.org/74172114:37
timburkeshanu_, clayg: yeah, we really need to get to addressing https://bugs.launchpad.net/swift/+bug/1813202 :-/14:40
openstackLaunchpad bug 1813202 in OpenStack Object Storage (swift) "s3api doesn't clean up multipart upload parts when MU is overwritten" [Undecided,New]14:40
claygtimburke: gah!  I could not find that when I was looking for it!14:41
timburkeit's currently rather annoying, though: we'd need to issue a delete that may take a long time to complete before we start reading any of the client bytes; as a result, the client may well time out before we've had a chance to start any backend PUTs14:42
claygdoes your SLO async delete API address the bug?14:42
timburkenot yet -- https://review.opendev.org/#/c/733026/ just makes that delete way faster -- there still need to be changes to s3api to do the HEAD-then-delete on top of it14:43
patchbotpatch 733026 - swift - Add a new URL parameter to allow for async cleanup... - 4 patch sets14:43
timburkenote that we could probably also address https://bugs.launchpad.net/swift/+bug/1691523 at the same time14:44
openstackLaunchpad bug 1691523 in OpenStack Object Storage (swift) "Multi-delete does not remove SLO segments" [Undecided,New]14:44
timburke(though for some reason, i thought we'd fixed that already...)14:44
timburkeoh! no, that's for the normal swift bulk-delete -- never mind, that'd be a completely unrelated change14:47
timburkes3api's delete-multiple will handle MPUs fine, though there was a bugfix not so long ago: https://github.com/openstack/swift/commit/b35fc4114:48
ormandjtimburke: oh man, that segments one explains a lot15:04
*** mikecmpbll has quit IRC15:10
*** mikecmpbll has joined #openstack-swift15:17
timburkeormandj, fwiw i wrote up a script that can clean up a single account at a time: http://paste.openstack.org/show/797781/15:23
timburkei think we maybe saw some issues under high concurrency15:24
timburkeormandj, cwright: oh! i thought of something late yesterday about the switch to servers-per-port -- you may want to change one server over, update the ring for that one server, push the updated ring out to all nodes, then repeat for each server15:32
timburkemoving slowly like that should help prevent availability issues15:32
claygtimburke: we ended up making sure that the first disk on a server used the same port as the old ring - that way even proxies were using old rings (as they do for 30 until they check the mtime) they can still connect (all servers can still route to ask disks)15:36
*** mikecmpbll has quit IRC16:01
ormandjtimburke: we will play it safe and do that, no problem at all, it's all automated anyways17:04
ormandjthank you for the head's up, we've had enough surprises :p17:04
ormandjtimburke: re: the cleanup, appreciate that too, but we will have to hope for the fix, because the manual workload + billing fun from doing that for thousands upon thousands of customers will not be pretty :)17:05
openstackgerritTim Burke proposed openstack/swift master: Authors/ChangeLog for 2.26.0  https://review.opendev.org/75053717:22
*** gyee has joined #openstack-swift17:31
*** gmann_afk is now known as gmann17:42
*** djhankb has quit IRC17:49
*** djhankb has joined #openstack-swift17:49
*** manuvakery has quit IRC18:27
ormandjso swift-dispersion-report got sorted in: https://bugs.launchpad.net/swift/+bug/146837418:36
openstackLaunchpad bug 1468374 in OpenStack Object Storage (swift) "swift dispersion does not support keystone auth v3" [Undecided,Fix released] - Assigned to Falk Reimann (falk-reimann)18:36
ormandjhowever, we're seeing the same issue with swift-dispersion-populate18:36
ormandjsorry, wrong bug: https://bugs.launchpad.net/swift/+bug/186368018:37
openstackLaunchpad bug 1863680 in OpenStack Object Storage (swift) "python3 swift-dispersion-report issue" [High,Fix released] - Assigned to Sam Morrison (sorrison)18:37
ormandjwe see what looks to be the same problem with populate re: python318:37
openstackgerritOpenStack Release Bot proposed openstack/python-swiftclient stable/victoria: Update .gitreview for stable/victoria  https://review.opendev.org/75138118:40
openstackgerritOpenStack Release Bot proposed openstack/python-swiftclient master: Update master for stable/victoria  https://review.opendev.org/75138218:40
openstackgerritOpenStack Release Bot proposed openstack/python-swiftclient master: Add Python3 wallaby unit tests  https://review.opendev.org/75138318:40
ormandjtimburke: was able to patch it to work, will link a diff18:40
openstackgerritTim Burke proposed openstack/swift master: py3: Fix swift-dispersion-populate  https://review.opendev.org/75138418:46
timburkeormandj, i'm guessing something like ^^^ ?18:46
timburkethanks for the report -- sorry i'd missed that somehow when i was fixing up the patch to -report18:47
ormandjtimburke: https://bugs.launchpad.net/swift/+bug/189534618:52
openstackLaunchpad bug 1895346 in OpenStack Object Storage (swift) "swift-dispersion-populate and python3" [Undecided,New]18:52
ormandjlol18:52
ormandjyeah you called it :p18:52
ormandjyou can close the report obviously18:53
ormandjsorry hadn't seen your message when i hit submit18:53
ormandjtimburke: in interesting news, we changed ring to update ports for server_per_port but didn't update the replication port18:56
ormandjhowever the replicator is trying to use the non-replication port18:56
ormandjand it's broken all replication :)18:56
ormandjwell, i should be more clear - let me write this up and i'll update - too much to stream of conscious in here. sorry :)18:57
ormandjprotip: no servers_per_port in replication configuration file. /ignoreme19:04
openstackgerritTim Burke proposed openstack/swift master: py3: Fix swift-dispersion-populate  https://review.opendev.org/75138419:35
timburkethat bug was great; i shouldn't have piggy-backed off the old one. updated the bug refs on ^19:36
openstackgerritClay Gerrard proposed openstack/python-swiftclient master: basic connection close tracking infra  https://review.opendev.org/75141819:47
claygtimburke: ormandj: I had "review s3api quota patch" on my todo list for today - is that p 749382 ???20:24
patchbothttps://review.opendev.org/#/c/749382/ - swift - s3api: Make quota-exceeded errors more obvious - 2 patch sets20:24
claygcause *that* looks like a big honkin' refactor tied up with a minor cosmetic improvement?20:25
timburkeclayg, yeah, that's the patch. sorry, it *is* getting away from me a bit21:22
timburkeif you'd rather, we could stick with something like the first patchset -- it's much more surgical, but at some point we need to admit that the look-up-table style of things there is insufficient for what we'd like to express21:22
claygit's just akward - i *like* the refactoring - normally what'd I do is try to play with some and see if I can "keep going" make it look _even better_ (because the process of changing the code will increase my confidence in the test coverage)21:45
claygbut OTOH, it obviously fixes the bug - so I'd also just like to :shipit:21:45
claygTENSION21:45
claygdo you have any sense of how well existing tests are exercising all of those status response transformations?21:46
claygmaybe i could just throw in a few name errors21:47
claygidk man that "raise KeyError" tho 🤮21:51
*** rcernin has joined #openstack-swift22:02
*** rcernin has quit IRC22:03
*** rcernin has joined #openstack-swift22:03
openstackgerritTim Burke proposed openstack/swift master: s3api: Make quota-exceeded errors more obvious  https://review.opendev.org/74938222:37
openstackgerritTim Burke proposed openstack/swift master: s3api: Refactor how we handle expected errors  https://review.opendev.org/75155522:37
*** gyee has quit IRC22:46
openstackgerritTim Burke proposed openstack/python-swiftclient master: Clean up some requirements  https://review.opendev.org/75047523:58

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!