Wednesday, 2019-08-07

*** camelCaser has quit IRC00:11
*** camelCas- has joined #openstack-swift00:11
openstackgerritMerged openstack/swift master: Use `is` to compare against sentinel object  https://review.opendev.org/67488300:32
timburkehow crazy would it be to track last object write for containers? we've already got the trigger to update object_count/bytes_used ... seems not *so* terrible...01:05
timburkei started poking at https://bugs.launchpad.net/swift/+bug/183409701:05
openstackLaunchpad bug 1834097 in OpenStack Object Storage (swift) "container-sharder has no latch when reporting stats" [Undecided,New]01:05
timburkeand got pretty far -- added a migration to add a (boolean) `reported` column to the shard table, mark it as such when we send an update to the root, skip doing the update if we're already marked reported...01:07
timburkebut then i ran into issues where one replica of a shard reports stats and latches, then another one does the same...01:08
timburkebut because we set the meta_timestamp to the time at which we're doing the reporting (https://github.com/openstack/swift/blob/2.22.0/swift/common/utils.py#L5018-L5021) the second replica updates the timestamp in the root01:09
timburkeso when the first replica comes 'round again, it checks in with the root, sees there's an update, so merges it and clears its reported flag01:11
timburkemaybe it's that last part that's really causing my problem? it feels like if i'm doing a merge i oughta clear it... but maybe if stats match i can leave it?01:12
openstackgerritTim Burke proposed openstack/swift master: WIP: latch shard-stat reporting  https://review.opendev.org/67501401:17
timburkewell, we'll see what robe tests look like on ^^^01:17
timburke*probe* tests, even01:17
timburkecan't wait for us to have https://review.opendev.org/#/c/671333/ ;-) it'll be so exciting!01:19
patchbotpatch 671333 - swift - py3: (mostly) port probe tests - 2 patch sets01:19
*** pcaruana has quit IRC01:26
*** gyee has quit IRC01:33
*** zaitcev_ has quit IRC01:40
*** zaitcev_ has joined #openstack-swift01:54
*** ChanServ sets mode: +v zaitcev_01:54
*** BjoernT has quit IRC02:43
*** BjoernT_ has joined #openstack-swift02:43
*** BjoernT_ has quit IRC02:47
*** BjoernT has joined #openstack-swift02:52
*** psachin has joined #openstack-swift03:36
*** ianychoi_ has joined #openstack-swift03:38
*** ianychoi has quit IRC03:42
*** pcaruana has joined #openstack-swift03:44
openstackgerritTim Burke proposed openstack/swift master: WIP: latch shard-stat reporting  https://review.opendev.org/67501403:45
*** diablo_rojo has joined #openstack-swift04:04
*** BjoernT has quit IRC04:12
openstackgerritTim Burke proposed openstack/swift master: Latch shard-stat reporting  https://review.opendev.org/67501405:07
*** diablo_rojo has quit IRC05:11
*** zaitcev_ has quit IRC05:21
*** zaitcev_ has joined #openstack-swift05:34
*** ChanServ sets mode: +v zaitcev_05:34
*** tdasilva_ has quit IRC05:36
*** patchbot has quit IRC05:46
*** patchbot has joined #openstack-swift05:48
*** zaitcev_ has quit IRC06:27
*** zaitcev_ has joined #openstack-swift06:41
*** ChanServ sets mode: +v zaitcev_06:41
*** ccamacho has joined #openstack-swift06:45
*** rcernin has quit IRC07:03
*** tesseract has joined #openstack-swift07:26
*** jistr is now known as jistr|afk07:42
*** spsurya has joined #openstack-swift07:50
*** mikecmpbll has joined #openstack-swift08:05
*** threestrands has quit IRC08:06
*** mauro|call has quit IRC08:13
*** mauro|call has joined #openstack-swift08:14
*** e0ne has joined #openstack-swift08:18
*** mikecmpbll has quit IRC08:35
*** mikecmpbll has joined #openstack-swift08:36
*** zaitcev_ has quit IRC08:51
*** mauro|call has quit IRC08:58
*** mauro|call has joined #openstack-swift09:00
*** tkajinam has quit IRC09:02
*** [diablo] has quit IRC09:02
*** [diablo]9 has joined #openstack-swift09:03
*** zaitcev_ has joined #openstack-swift09:04
*** ChanServ sets mode: +v zaitcev_09:04
*** mauro|call is now known as takamatsu09:14
*** jistr|afk is now known as jistr09:54
*** mvkr has joined #openstack-swift10:36
*** jistr is now known as jistr|call12:37
*** BjoernT_ has joined #openstack-swift13:36
*** tesseract has quit IRC13:56
*** tesseract has joined #openstack-swift13:57
*** tesseract has quit IRC14:00
*** tesseract has joined #openstack-swift14:01
*** mvkr has quit IRC14:12
*** zaitcev_ has quit IRC14:26
*** jistr|call is now known as jistr14:36
*** zaitcev_ has joined #openstack-swift14:40
*** ChanServ sets mode: +v zaitcev_14:40
*** altlogbot_2 has quit IRC14:46
*** altlogbot_2 has joined #openstack-swift14:47
*** ianychoi_ is now known as ianychoi14:54
openstackgerritTim Burke proposed openstack/swift master: Latch shard-stat reporting  https://review.opendev.org/67501415:00
*** zaitcev_ has quit IRC15:06
*** zaitcev_ has joined #openstack-swift15:20
*** ChanServ sets mode: +v zaitcev_15:20
*** diablo_rojo has joined #openstack-swift15:48
*** tesseract has quit IRC15:58
*** tesseract has joined #openstack-swift16:02
*** henriqueof has quit IRC16:02
*** gyee has joined #openstack-swift16:05
claygIf a symlink with a ``X-Symlink-Target-Etag`` targets a static large object manifest it will carry forward the SLO size and etag in the container listing the ``symlink_bytes`` and ``slo_etag`` keys.  However, manifests created before swift v2.12.0 (released Dec 2016) do not contain enough metadata to propogate the extra SLO information to the listing.16:27
clayg🤮16:27
claygtimburke: Is there anyway I can make this sound like less of total tire fire?16:28
*** psachin has quit IRC16:30
*** baojg has quit IRC16:38
*** tesseract has quit IRC16:39
timburkeclayg, all software is terrible -- despite that, some software's useful16:40
*** mikecmpbll has quit IRC16:40
timburkei guess the good news is that the slo_etag came after the size sysmeta? so at least clients have a way to identify data that should be copied over itself if they really want to fix it?16:42
timburkeit just involves doing a full listing and then heading every object that *doesn't* have slo_etag to see if it's in fact an slo 🤮16:44
*** baojg has joined #openstack-swift16:44
*** baojg has quit IRC16:44
*** baojg has joined #openstack-swift16:44
*** baojg has quit IRC16:45
*** baojg has joined #openstack-swift16:45
timburkei'm not actually sure i've got the right recommendation on https://bugs.launchpad.net/swift/+bug/1839355 ...16:45
openstackLaunchpad bug 1839355 in OpenStack Object Storage (swift) "container-sharder should keep cleaving when there are no rows" [Undecided,New]16:45
*** baojg has quit IRC16:45
timburkemaybe we should stop aborting replication on "small" DBs? let any rows land as misplaced objects in the root, get dealt with there...16:46
*** baojg has joined #openstack-swift16:46
*** baojg has quit IRC16:46
*** baojg has joined #openstack-swift16:47
*** baojg has quit IRC16:47
*** baojg has joined #openstack-swift16:48
*** baojg has quit IRC16:48
*** baojg has joined #openstack-swift16:48
*** baojg has quit IRC16:48
*** baojg has joined #openstack-swift16:50
*** baojg has quit IRC16:50
*** baojg has joined #openstack-swift16:51
*** baojg has quit IRC16:51
*** baojg has joined #openstack-swift16:51
*** baojg has quit IRC16:51
*** baojg has joined #openstack-swift16:52
*** baojg has quit IRC16:52
*** baojg has joined #openstack-swift16:53
*** baojg has quit IRC16:53
*** baojg has joined #openstack-swift16:54
*** baojg has quit IRC16:54
*** baojg has joined #openstack-swift16:54
*** baojg has quit IRC16:55
*** baojg has joined #openstack-swift16:55
*** baojg has quit IRC16:55
*** baojg has joined #openstack-swift16:56
*** diablo_rojo__ has joined #openstack-swift16:56
*** baojg has quit IRC16:56
*** diablo_rojo has quit IRC16:56
*** baojg has joined #openstack-swift16:57
*** baojg has quit IRC16:57
claygmaybe instead of limiting on cleave_batch_size we could do timeboxed?16:57
*** baojg has joined #openstack-swift16:57
*** baojg has quit IRC16:58
claygdo you estimate a fix for lp bug #1834097 significantly reduce the 11 day window?16:58
openstackLaunchpad bug 1834097 in OpenStack Object Storage (swift) "container-sharder has no latch when reporting stats" [Undecided,In progress] https://launchpad.net/bugs/183409716:58
*** baojg has joined #openstack-swift16:58
*** baojg has quit IRC16:58
timburkei'm seeing log lines like "Cleaved ... for shard range ... in 0.063s." so i'd guess we could do the whole think in like 2mins17:05
timburkei forget how long it usually takes to cleave a *full* range...17:06
*** e0ne has quit IRC17:06
*** altlogbot_2 has quit IRC17:17
*** altlogbot_2 has joined #openstack-swift17:24
*** altlogbot_2 has quit IRC17:31
*** henriqueof has joined #openstack-swift17:33
*** altlogbot_0 has joined #openstack-swift17:35
clayg10m?  30m?  2hr?  it depends on how busy the disks are17:58
ormandjheya folks - how are people dealing with large file uploads with segments, where failures happen on upload so there's segments that exist but aren't actually referenced in a manifest18:00
claygif num_batches > cleave_batch_size and time.time() - start > cleave_batch_min_thrash:18:01
ormandjthis happens more than we'd like and it consumes space that end users don't know/understand :)18:01
claygormandj: what's your operating use-case?  I think public operators probably "solve" the issue by charging customers, and private clusters do audits?18:03
claygI'm not aware of any solutions that for example add an x-delete-after 24 hrs when uploading segments and then do a POST to each segment to clear it after writing the manifest... but clients could probably get the cluster to help if they were real explicit about what they want...18:04
ormandjclayg:  use case is internal or external. let's say, hypothetically, you have a website that people can 'click to upload' files, including large files. user gets tired about 24 hours into an upload on their 2400 baud acoustic coupler, and shuts down their pc.18:06
ormandjthey fire it up again the next day and see this empty bucket, yet data consumed18:06
ormandjthey see it's in a segments bucket and go wtf18:06
ormandjwhat's a segment?18:06
ormandjobviously we don't want to expose any user to this kind of thing, since they shouldn't have to care about any of it18:07
ormandjwe were considering writing something that pulls all manifests and does an audit with the segments and if the segments exist but don't have a manifest entry, they are orphaned18:07
ormandjotherwise we have a ton of orphaned segments18:07
ormandjand especially if users have tons of uploads into the bucket w/ other large objects18:08
ormandjit's a nightmare just telling users to 'figure it out'18:08
*** diablo_rojo__ is now known as diablo_rojo18:13
ormandjclayg:  i just didn't know if there's a built in way to handle orphaned segments like this, or if it was something anyone had thought about - i would imagine it's a pretty large problem for anyone regardless of usage, if they have large objects that get segmented18:16
*** spsurya has quit IRC18:22
claygYou're right that it's something people have thought about, and in your situation the conclusion would be like: "the website/application would handle the client error/disconnect by cleaning up segments it uploaded for which it didn't upload a manifest"18:25
claygThat fails when the appliation fails - and it would be an improvement if there was a "built in" way to expire unreferenced segments18:26
claygHowever currently the API doesn't decorate segment uploads in such a way as to identify them as segments - they're just objects which can be combined later when a client uploads a manifest.18:26
claygI think the object-expiration feature could be useful for application authors that need their segments to expire automatically if the uploading application dies w/o writing a manifest.. but that'd be up to the client since they'd also need to *clear* the expiration/timeout after they upload the manifest18:29
ormandjclayg:  yeah, unfortunately, that example is just the website, reality is, we have a ton of rando-clients doing things :)18:30
ormandjand as you know, success in getting clients to do anything correctly is generally somewhere around 0%18:30
ormandjso we have to figure out a server-side way of handling this. would have been nice if we required manifest first, then segments for large object uploads18:31
ormandjjimmies-first-javaproject-0.0.1.jar is one of the clients we have to account for, so we're trying to figure out a good way to handle this transparently for end users, since we can't expect them to clean up segments related to bad client behavior18:32
claygormandj: yeah, i think that would be nice too - I've not heard anyone ever offer to work on that at PTG or anything... you could probably cook up a custom middleware to make a SLO++18:33
ormandjnot much value in it now since it's already implemented, nobody is gonna go update clients (same problem) :p18:34
ormandjguess we'll just have to figure out a way to handle it on the backend with manifest/segment audits18:34
claygormandj: maybe... if you have no control of clients... how can you tell if any given object is a SLO segment or just... a regular object?  huristic on the naming conventions?18:37
ormandjthe clients all seem to drop stuff in a segments bucket18:40
ormandj(we are s3 compat facing outwards)18:40
claygtimburke: what was the name you came up with for the new kind of *LOs that would have a multi-part upload id with expiration kind of thing?18:40
claygormandj: oh, s3api is different - are you running the latest version?18:41
timburkeALO, i think? like, atomic large object, or something18:41
ormandjclayg:  stein's built-in, yes18:42
timburkethen expose something like S3's "clean up segments for incomplete uploads more than X days old"18:42
ormandjclayg:  you'll probably see a bug report from me regarding stein and keystone w/ py3, i ended up having to patch it internally to even make it work hah :) but yes, we're all stein now18:43
timburkeormandj, what version of swift are you running? 2.21.0?18:45
timburkethere's been a bunch of py3-related fixes since then :-)18:45
timburkeor was the issue some interaction between swift-on-py2 and keystone-on-py3?18:45
ormandjhttps://bugs.launchpad.net/keystone/+bug/183373918:47
openstackLaunchpad bug 1833739 in OpenStack Identity (keystone) "keystone (stein), python3, and postgresql: hex in database" [High,Triaged]18:47
*** mvkr has joined #openstack-swift18:47
ormandji fixed it internally with a patch, but it's not the 'right' solution so i didn't submit it upstream, as you should be handling this for every case, not just this specific one. i just didn't have time to implement the proper fix, but i did suggest it in this channel back when i found the bug18:47
*** BjoernT has joined #openstack-swift18:48
timburkeah, cool. i think i was looking at that recently, though i don't remember why -- sounds kinda familiar tho :-)18:48
timburke"but i did suggest it in this channel back when i found the bug" heh, maybe that's why it sounded familiar18:48
ormandjprobably :)18:49
claygormandj: so with s3api you have at least ListMultipartUploads, but currently we don't have anything like their LifecycleManagement that automatically scans and reaps Incomplete Multipart Uploads.18:49
*** e0ne has joined #openstack-swift18:49
ormandjclayg:  yeah, that's what i expected, i was just hopeful i missed something18:50
ormandjcrushing my dreams again clay, crushing my dreams...18:50
*** BjoernT_ has quit IRC18:50
claygormandj: ask timburke to tell you more about how great ALO's will be someday18:50
clayghe's a dreamer18:50
claygwe'll probably have s3 compatible lifecycle management via 1space before we have ALOs  🤔18:51
*** BjoernT_ has joined #openstack-swift19:15
*** BjoernT has quit IRC19:17
openstackgerritTim Burke proposed openstack/python-swiftclient stable/rocky: Fix up stable gate  https://review.opendev.org/67518419:18
*** camelCas- has quit IRC19:38
*** e0ne has quit IRC19:46
*** ndk_ has joined #openstack-swift20:07
openstackgerritMerged openstack/python-swiftclient stable/stein: Fix up stable gate  https://review.opendev.org/67418020:39
*** tdasilva has joined #openstack-swift20:51
*** ChanServ sets mode: +v tdasilva20:51
kota_morning20:57
timburkeo/20:59
kota_timburke: o/20:59
timburketdasilva, mattoliverau meeting time21:01
*** diablo_rojo has quit IRC21:07
*** diablo_rojo has joined #openstack-swift21:08
*** BjoernT_ has quit IRC21:08
*** camelCaser has joined #openstack-swift21:09
openstackgerritClay Gerrard proposed openstack/swift master: Allow "harder" symlinks  https://review.opendev.org/63309421:20
ormandjclayg:  haha, fair enough.21:22
*** henriqueof has quit IRC21:33
clayg👍21:41
*** zaitcev_ is now known as zaitcev21:44
*** diablo_rojo has quit IRC21:46
openstackgerritTim Burke proposed openstack/python-swiftclient stable/stein: Fix SLO re-upload  https://review.opendev.org/67332121:51
*** diablo_rojo has joined #openstack-swift22:05
openstackgerritMerged openstack/swift master: py3: port RBAC func tests  https://review.opendev.org/67470322:10
*** diablo_rojo has quit IRC22:10
*** rcernin has joined #openstack-swift22:15
*** notmyname has quit IRC22:45
*** patchbot has quit IRC22:59
*** tdasilva has quit IRC23:02
*** tdasilva has joined #openstack-swift23:02
*** ChanServ sets mode: +v tdasilva23:02
*** notmyname has joined #openstack-swift23:15
*** ChanServ sets mode: +v notmyname23:15
*** patchbot has joined #openstack-swift23:15
*** zaitcev_ has joined #openstack-swift23:16
*** ChanServ sets mode: +v zaitcev_23:16
openstackgerritTim Burke proposed openstack/swift master: py3: mostly port s3 func tests  https://review.opendev.org/67471623:19
openstackgerritTim Burke proposed openstack/swift master: py3: Finish porting s3 func tests  https://review.opendev.org/67522723:19
*** zaitcev has quit IRC23:20
openstackgerritTim Burke proposed openstack/swift master: py3: Cover account/container func tests  https://review.opendev.org/64538823:23
openstackgerritTim Burke proposed openstack/swift master: py3: port dlo func tests  https://review.opendev.org/64292023:24
*** hoonetorg has quit IRC23:26
*** hoonetorg has joined #openstack-swift23:39
openstackgerritMerged openstack/python-swiftclient stable/rocky: Fix up stable gate  https://review.opendev.org/67518423:45
openstackgerritMerged openstack/swift stable/stein: Imported Translations from Zanata  https://review.opendev.org/67447723:51
*** tdasilva has quit IRC23:51
*** tdasilva has joined #openstack-swift23:52
*** ChanServ sets mode: +v tdasilva23:52
*** tdasilva has quit IRC23:55
*** tdasilva has joined #openstack-swift23:56
*** ChanServ sets mode: +v tdasilva23:56

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!